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Abstract 

The  1985  National  Defense  Authorization  Act  required  the  U.S.  Government  to 
maintain  the  public  capability  to  sustain  military  systems  that  play  a  role  in  war  plans  and 
contingency  scenarios  -  referred  to  as  “core”.  This  research  analyzes  application  of  this 
law  to  the  modification  of  fielded  USAF  manned  combat  aircraft  Operational  Flight 
Programs  (OFPs). 

First,  a  review  of  the  content  and  history  of  the  law  and  implementing  policies 
was  performed.  The  intent  of  Title  lO’s  core  requirement  was  analyzed  with  respect  to 
the  risk  of  relying  on  private  sector  depot  maintenance  in  today’s  environment. 

Next,  models  were  developed  as  a  tool  for  determining  whether  OFP  work  is 
more  appropriately  designated  as  maintenance  or  development.  The  models  were  applied 
to  current  combat  aircraft  OFPs,  and  results  suggest  that  most  OFP  modification  is 
development  and  not  maintenance.  Foundational  to  the  models,  a  common  lexicon  is 
proposed  with  definitions  of  “software  maintenance”  and  other  key  terms. 

Lastly,  a  new  model  for  source  of  repair  decisions  is  proposed  which  includes  a 
risk  analysis  for  all  depot  work,  regardless  of  core  designation.  Beneficial  to  program 
offices,  depot  organizations,  and  HQ  AFMC,  this  framework  allows  greater  flexibility 
and  cost  savings  by  emphasizing  competition  based  on  cost  effectiveness. 
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CORE  LOGISTICS  CAPABILITY  POLICY  APPLIED  TO  USAF  COMBAT 
AIRCRAFT  AVIONICS  SOFTWARE:  A  SYSTEMS  ENGINEERING  ANALYSIS 

I.  Introduction 


DoD  increasingly  relies  on  software  to  introduce  or  enhance  performance  of  weapon 
systems,  and  making  software  adjustments  is  increasingly  a  key  component  of 
maintaining  systems  to  prepare  for  emergency  conditions. 

(Government  Accountability  Office,  2009) 


The  role  of  software  as  the  most  critical  part  of  weapons  systems  is  growing.  As  an 
example,  80%  of  the  functionality  in  modern-day  aircraft  like  the  F-35  JSF  is  dependent 
on  software.  (Naval  Air  Systems  Command,  2008) 

Background 

The  United  States  government  has  an  interest  in  retaining  control  over  and 
expertise  in  the  maintenance  and  repair  of  weapons  systems  used  in  time  of  war  or 
significant  military  action.  The  motivation  for  this  requirement  is  mentioned  in  a  single 
line  of  the  law:  to  ensure  a  “ready  and  controlled  source  of  technical  competence  and 
resources  necessary  to  ensure  effective  and  timely  response  to  a  mobilization,  national 
defense  contingency  situations,  and  other  emergency  requirements”  (Title  10  U.S.  Code, 
Sec.  2464,  2006  ed).  This  interest  was  expressed  in  the  1985  National  Defense 
Authorization  Act  and  codified  into  law,  generating  cascading  layers  of  DoD  and  USAF 
policy  detailing  this  interest  and  its  implementation.  Logistics  capabilities  required  for  the 
sustainment  of  weapons  systems  that  play  a  role  in  major  war  scenarios  are  designated 
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“core”  capabilities,  requiring  government  facilities,  government  equipment,  and 
government  personnel  to  perform  a  significant  portion  of  sustainment  work. 

In  short,  the  government’s  expressed  interest  in  control  over  core  logistics 
functions  is  insulation  from  the  risk  of  total  reliance  on  a  private  contractor  for 
sustainment  of  critical  weapons  systems. 

Over  the  past  two  decades,  policies  and  regulations  detailing  the  designation  of 
systems  as  “core”  and  specifying  their  logistics  planning  requirements  have  grown  in 
quantity  and  detail  and  have  also  changed  in  emphasis.  The  mid-1990s  saw  a  significant 
push  toward  contractor  logistics  support.  Then  in  the  late  1990s,  Congress  expressed 
concern  over  excessive  reliance  on  the  private  sector  for  depot-level  logistics  support  of 
major  weapons  systems.  As  a  result  of  this  pendulum  swing,  the  DoD  published  new 
guidance  in  2002  allowing  and  defining  public-private  partnerships  for  depot-level 
maintenance  of  “core”  systems.  The  2002  guidance  meant  to  satisfy  the  requirements  of 
the  law  and  retained  the  advantages  of  contractor  involvement. 

Implementation  of  the  1985  law  has  proved  troublesome  as  long  system 
development  timelines  span  significant  changes  in  technology,  industry  landscape, 
political  winds,  and  policy  emphasis.  Compounding  the  challenge  is  the  shift  from 
hardware-centric  military  systems  to  systems  permeated  or  dominated  by  software. 
Definitions  of  software  maintenance  and  software  sustainment  in  policy  documents  and 
military  regulations  are  inconsistent  at  best  and  non-existent  in  some  key  documents.  In 
some  cases  the  requirement  for  the  government  to  maintain  software  is  added  to  existing 
hardware  sustainment  policy  with  a  single  sentence  or  cursory  explanation. 
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Have  the  law,  DoD  policy,  Air  Force  regulations,  and  logistics  paradigms  kept 
pace  with  the  increasingly  central  role  of  software  in  weapons  systems?  Should  the  shift 
from  protracted  war  toward  smaller  shorter  conflicts  result  in  changes  to  policy?  Is  the 
process  by  which  maintenance  workloads  are  designated  as  “core”  adaptable  and  flexible 
to  the  myriad  differences  in  system  architecture  and  program  history?  Caught  between 
the  law  and  the  constraints  and  expense  of  government  depot-level  maintenance,  program 
managers  are  increasingly  frustrated  about  how  to  transition  from  contractor  to 
government  logistics  support,  especially  when  government  depot  maintenance  was  not 
envisioned  or  planned  at  a  program’s  inception. 
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Figure  1.  Acquisition  landscape 


The  depot-level  maintenance  landscape  today  (Figure  1)  is  a  confusing  whirlwind 
of  evolving  policies,  varying  interpretation  between  the  services,  a  shrinking  industrial 
base,  political  intolerance  of  budget-overruns,  and  rapid  technical  innovation.  In  this 
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environment,  implementing  long-term  logistics  support  for  complex  systems  whose 
development  may  span  a  decade  or  more  is  a  significant  challenge. 

The  increasing  role  of  software  (Figure  2)  compounds  the  problem  because 
software  is  forced  into  existing  hardware-centric  paradigms  and  definitions.  Aircraft 
avionics  Operational  Flight  Programs  (OFPs)  are  one  example  of  software  that  is 
developed  and  sustained  amidst  a  confusing  mix  of  policies  primarily  geared  toward 
hardware. 
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Figure  2.  Increasing  role  of  software  in  aircraft 
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Problem  Statement 


The  history  and  evolution  of  eore  logistics  law  and  policy  is  difficult  to 
comprehend  yet  critical  to  understanding  and  applying  law  and  policy  today.  Definitions 
of  key  terms  are  inconsistent  or  lacking,  further  increasing  the  difficulty  of  understanding 
and  applying  policy. 

This  research  addresses  the  history  and  motivation  of  core  logistics  law  and  policy 
and  analyzes  differences  between  hardware  and  software  maintenance.  This  research 
also  strives  to  allow  better  understanding  of  the  complex  web  of  law,  policy,  and  practice. 
A  common  dictionary  of  terms  is  developed  for  use  in  policy  and  regulations,  and  models 
for  differentiating  between  OFP  maintenance  and  development  are  created.  When 
combined  with  clear  definitions,  these  models  could  bring  rigor  to  avionics  software 
source  of  repair  decisions. 

Scope  of  Research 

While  some  aspects  of  this  research  are  applicable  to  software  and  hardware 
sustainment  in  general,  the  specific  target  is  the  development  and  depot  level  sustainment 
of  the  central  integrating  software  in  manned  Air  Force  combat  aircraft  systems.  The 
central  integrating  software  is  commonly  called  the  Operational  Flight  Program. 

OFPs  are  typically  compilations  of  many  lower  level  avionics  software  packages 
that  together  acquire,  process,  transmit,  and  display  information,  data,  and  signals  in 
conjunction  with  aircraft  specific  hardware.  A  central  OFP,  run  by  the  primary  aircraft 
computer,  integrates  the  subordinate  OFPs  which  run  various  components  such  as  a  radar 
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or  electronic  warfare  suite.  Central  or  integrating  OFPs  are  typically  updated  every  one  to 
several  years  and  are  developed  for  a  specific  aircraft  major  design  series. 

The  scope  of  the  research,  therefore,  is  limited  to  the  intersection  of  Title  10  core 
capability  requirements,  software,  and  manned  USAF  airborne  combat  systems.  Figure  3 
is  a  Venn  diagram  which  visually  depicts  the  research  boundary. 


Research  Boundary 


Conclusions  Up  Front 

Four  conclusions  are  here  stated  and  later  defended,  to  highlight  both  the  current 
challenges  and  potential  solutions: 

1 .  The  taxonomy  in  use  within  the  DoD,  with  regard  to  software  maintenance,  is 
inconsistent  and  vague.  A  clear,  common,  and  consistent  glossary  should  be 
included  in  DoD  and  Air  Force  policy  documents.  This  research  will  propose 
clear  definitions  to  guide  implementation  of  policy. 

2.  Military  aircraft  OFF  workload  post-deployment  is  normally  not  software 
maintenance  and  should  not  be  designated  “core”  by  default.  Additionally,  the 
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source  of  modification  for  OFPs  is  typically  conducted  once  in  the  software 
lifecycle.  This  research  will  develop  a  tool  to  aid  in  properly  categorizing  OFF 
modifications  as  either  new  development  or  maintenance.  Additionally,  this 
research  proposes  performing  a  source  of  modification  decision  prior  to  the 
fielding  of  each  OFF. 

3.  This  research  does  not  advocate  replacing  government  depots  with  private  depots. 
It  does,  however,  advocate  the  continued  cooperation  between  government  depots 
and  private  industry  through  the  implementation  of  Fublic-Frivate  Partnerships 
(PPP).  PPPs  will  allow  for  the  smooth  transition  of  work  between  private 
industry  and  government  depots. 

4.  Title  10  does  not  currently  allow  for  risk  assessments  or  cost  effectiveness  to 
weigh  in  the  source  of  repair  decision.  This  research  will  show  the  risks 
associated  with  private  sustainment  of  military  systems  has  diminished  since  the 
law  was  written  and  therefore  risk  and  cost  effectiveness  should  now  be 
considered  when  identifying  core  capabilities. 

5.  The  requirement  in  Title  10  Section  2464  to  establish  an  organic  maintenance 
capability  within  four  years  of  Initial  Operating  Capability  (IOC)  is  arbitrary  and 
best  applied  to  hardware.  Title  10  should  be  amended  to  require  the  DoD  to 
identify  depot  workload  allocations  based  on  the  particular  attributes  of  the 
system  under  consideration. 
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Flow  of  the  Areument 


After  laying  the  foundation  with  a  review  of  relevant  law  and  poliey,  the  explieit 
and  implicit  intent  of  the  requirement  for  government  to  maintain  a  core  logistics 
capability  is  examined.  The  research  then  describes  the  current  application  of  Title  10 
requirements  to  software  modifications  and  defines  “software  maintenance”  by 
comparing  and  contrasting  it  with  “hardware  maintenance”.  A  common  dictionary  of 
terms  is  then  proposed.  Next,  this  understanding  is  applied  to  the  issue  of  OFF  updates, 
arguing  that  most  (but  not  all)  OFF  development  is  development  and  not  maintenance. 
We  introduce  a  model  that  categorizes  an  OFF  effort  as  primarily  “maintenance”  or 
“development”.  Lastly  these  findings  and  model  are  integrated  in  proposing  a  more 
flexible  model  for  OFF  lifecycle  planning — a  model  that  satisfies  the  law,  retains 
government  depot  maintenance  capability,  and  allows  for  differences  in  OFF  type  and 
use.  Figure  4  depicts  the  flow  of  this  presentation  pictorially  with  chapter  numbers. 


Flow  of  the  Argument 
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Figure  4.  Argument  outline 
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Another  way  of  looking  at  the  flow  of  this  paper  is  depicted  in  Figure  5.  This 
highlights  the  importance  of  definitions  in  understanding  the  history  and  future  of 
software  policy  and  education. 
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II.  Law  and  Policy  History 


Introduction 

The  last  15  years  have  been  characterized  by  a  tension  between  Title  lO’s  core 
logistics  requirement  and  Department  of  Defense  policy.  Agencies  such  as  the 
Government  Accountability  Office  are  attempting  to  highlight  law  and  policy  disparities 
between  two  parties  with  different  interests. 

Newcomers  to  the  core  logistics  discussion  are  in  for  a  slow  and  confusing 
education  if  only  current  law  and  policy  are  considered.  One  encounters  layers  of 
evolving  instructions  with  little  commentary  on  why  and  when  policy  changes  were 
made.  The  following  summary  is  a  primer  of  the  law  and  its  downstream  policy. 

Research  methods  used  in  this  examination  of  law  and  policy  history  included  a 
review  of  the  text  of  Title  10  and  its  changes  over  time,  a  consolidation  of  existing 
analyses  performed  by  the  Government  Accountability  Office  (GAO)  and  the 
Congressional  Budget  Office  (CBO),  and  study  of  Congressional  notes  that  are  included 
in  the  text  of  public  law  which  established  Title  10  core  logistics  requirements.  The  text 
of  the  law  and  summaries  of  relevant  policy  documents  and  government  reports  are 
included  in  Appendices  B-E. 

Early  Years 

The  trail  of  depot  maintenance  challenges  can  be  traced  back  to  World  War  II 
(Figure  6).  This  is  especially  true  for  aircraft.  The  1940’s  saw  a  fledgling  aircraft  industry 
pushed  to  its  limits  producing  the  vast  quantities  of  aircraft  required  to  fight  the  war. 
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Little  excess  capacity  was  available  to  maintain  those  aircraft  (Congressional  Budget 
Office,  1995).  The  solution  at  the  time  was  to  create  an  unspoken  divide  between  the 
producer  (the  private  sector)  and  the  maintainer  (the  public  sector). 


Figure  6.  WWII  bomber  formation 


The  historic  notion  that  the  government  is  solely  responsible  for  depot  level 
maintenance  of  aircraft  therefore  came  about  by  the  chance  event  of  a  major  war 
coincident  with  an  unprepared  industrial  base.  This  paradigm  continues  today  even 
though  the  rationale  behind  the  division  of  labor  has  long  been  forgotten. 

Cold  War 

Understanding  the  nature  of  military  conflicts  that  immediately  preceded  the  1985 
Title  10  organic  core  logistics  law  is  critical  to  the  task  of  interpreting  and  applying  the 
law.  The  United  States  had  a  monolithic  and  clearly-identifiable  enemy  in  the  Soviet 
Union.  American  soldiers  were  frequently  tested  on  their  knowledge  of  Soviet  guns, 
ships,  tanks,  and  aircraft.  Would-be  American  aces  memorized  silhouettes  of  Soviet 
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aircraft — Floggers,  Fencers,  Fulcrums,  and  Flankers.  The  U.S.  military  knew  the 
enemy — ^his  location,  equipment,  doctrine,  and  his  uniform.  The  Cold  War  was  conflict 
for  the  long  haul.  A  war  would  be  long  and  ugly,  and  U.S.  aircraft  might  spend  years  in 
the  European  theater  slogging  it  out  against  red  stars  painted  on  cold  steel  and  aluminum 
(Congressional  Budget  Office,  1994). 

Because  of  the  protracted  Cold  War  scenario,  the  American  people  could  ill 
afford  to  chance  their  fate  to  the  whims  of  a  private  contractor  more  interested  in 
developing  the  next  generation  of  aircraft  than  sustaining  the  current  fleet.  There  was 
great  concern  that  private  depots  would  not  be  able  to  keep  up  with  the  surge  in  work 
expected  if  war  broke  out.  Placing  the  depot  maintenance  under  government  control  was 
the  only  way  to  assuage  the  risk  (Congressional  Budget  Office,  1995). 

Contrast  this  picture  with  today’s  wars,  which  differ  greatly  from  war  envisioned 
during  the  Cold  War.  What  uniform  does  the  enemy  wear?  Where  is  he  hiding?  Where 
will  the  next  bomb  blast  be  heard?  Military  engagements  today  are  short  but  frequent, 
less  predictable,  with  an  elusive  enemy,  and  no  end  is  in  sight.  As  evidenced  by  the 
personal  military  experience  of  this  research  team,  our  military  aircraft  rarely  spend  more 
than  a  few  weeks  or  months  in  theater  before  rotating  home  for  fresh  crews  and  fresh  jets. 

Additionally,  the  nature  of  the  industrial  base  has  changed.  Fewer  new  systems 
are  being  developed  and,  some  would  argue,  shifting  depot  maintenance  to  the  private 
sector  is  critical  to  ensuring  the  long  term  viability  of  the  contractors  (Congressional 
Budget  Office,  1995).  The  economics  of  the  modem  world  have  more  closely  aligned  the 
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interests  of  the  government  and  private  industry  potentially  redueing  risks  that  were 
unbearable  in  the  1980s. 

The  nature  of  war  has  ehanged  greatly  between  1980  and  2010.  The  changes 
have  informed  the  laws  codified  in  Congress  and  the  policies  penned  in  the  Pentagon. 
This  study  will  highlight  those  changes  and  how  they  have  often  failed  to  keep  pace. 

Title  10  of  the  United  States  Code 

The  requirement  for  the  United  States  to  maintain  an  organic  depot  maintenance 
capability  began  with  the  National  Defense  Authorization  Act  (NDAA)  of  1985.  As 
previously  mentioned,  the  United  States  was  firmly  embroiled  in  the  Cold  War  in  1985 
and  government  run  depots  had  been  the  norm  since  World  War  II.  Why  did  the  U.S. 
Congress  see  the  need  to  codify  a  practice  that  was  normative  for  nearly  45  years? 
Shortly  after  World  War  II,  the  DoD  and  the  Air  Force  began  shifting  depot  maintenance 
responsibilities  to  the  private  sector  (Congressional  Budget  Office,  1995).  This 
culminated  with  a  DoD  policy  in  1982  restricting  the  amount  of  work  done  in 
government  depots  to  a  maximum  of  70  percent.  The  1985  NDAA  can  be  viewed  as  a 
Congressional  response  to  a  perceived  DoD  trend  towards  privatization.  Since  1982, 
detail  has  been  added  and  allowable  ratios  between  government  and  contractor  depot 
maintenance  varied. 
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These  ehanges  in  the  allowable  proportion  of  work  allocated  to  the  government 
are  here  summarized  (Government  Accountability  Office,  2008)  and  depicted  in  Figure  7: 

•  1982  -DoD  directed  that  services  plan  for  not  more  than  70  percent  of  depot 
maintenance  to  be  repaired  at  organic  [military]  depots. 

•  1985  -NDAA  required  the  government  to  maintain  a  core  logistics  capability. 

•  1992  -NDAA  set  a  60  percent  floor  for  organic  depot  maintenance. 

•  1996  -DoD’s  policy  shifted  to  relying  more  on  the  private  sector  for  depot 
maintenance. 

•  1998  -NDAA  established  that  no  more  than  50  percent  of  depot  maintenance 
funding  can  be  allocated  to  the  private  sector. 

•  1998  -Definition  of  depot  maintenance  in  Section  2460  of  Title  10  expanded  to 
include  all  depot  level  maintenance  and  repair  workload  regardless  of  location  of 
where  the  work  was  performed  and  specifically  included  software  maintenance. 


Policy  Trends  in  Organic  (Gov)  Depot  Requirements 


No  limits 


DoD  policy:  70%  organic  depot  workload  maximum 


1984  N  DAA  requires  core  logistics  capability 


1991  NDAA:  60%  oreanic  workload  minimum 

•  • 

1995  NDAA:  60%  organic func/mo  minimum(CBO) 
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Figure  7.  Policy  trends  in  organic  depot  requirements 
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Title  10  Sec  2464  (link  to  full  text) 

Established  in  1985,  Section  2464  is  foundational  to  the  core  logistics  discussion. 
Section  2464  requires  the  United  States  to  maintain  an  organic  (government-owned)  core 
logistics  capability,  consisting  of  the  triad  of  government-owned  equipment  operated  by 
government  employees  in  government  facilities.  Section  2464  also  gives  the  power  of 
identifying  core  logistics  capabilities  to  the  Secretary  of  Defense  and  specifically 
mentions  only  a  single  motivation  for  this  law:  ensure  a  “ready  and  controlled  source  of 
technical  competence  and  resources  necessary  to  ensure  effective  and  timely  response  to 
a  mobilization,  national  defense  contingency  situations,  and  other  emergency 
requirements”.  In  addition  to  identifying  core  capabilities,  the  Secretary  of  Defense  is 
required  to  identify  the  workload  necessary  to  maintain  these  capabilities  (Title  10  U.S. 
Code,  Sec.  2464,  2006  ed). 

Further,  Section  2464  defines  a  “logistics  capability”  as  those  capabilities 
necessary  to  “maintain  and  repair”  our  weapon  systems  and  other  military  equipment 
identified  as  necessary  for  the  fulfillment  of  strategic  and  contingency  plans  prepared  by 
the  Chairman  of  the  Joint  Chiefs  of  Staff.  In  summary,  this  law  requires  that  government 
depots  have  the  capability  to  maintain  all  weapon  systems  or  equipment  that  play  a  vital 
role  in  our  war/contingency  plans. 

It  is  important  to  note  that  this  law  does  not  require  the  government  to  perform  all 
maintenance  and  repair  on  critical  military  systems;  it  only  requires  the  government  to 
maintain  the  capability  to  maintain  and  repair.  As  will  be  discussed  later,  the  workloads 
associated  with  this  capability  depend  on  expected  workloads  during  time  of 
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war/contingency  and  the  government’s  ability  to  surge  to  higher  workloads  when 
required.  Section  2464  requires  that  this  core  capability  be  established  “not  later  than 
four  years  after  achieving  initial  operational  capability’’  (Title  10  U.S.  Code,  Sec.  2464, 
2006  ed). 

Interestingly,  this  foundational  law  does  not  refer  to  maintaining  a  core  “depot” 
maintenance  capability.  It  mentions  only  “maintenance  and  repair”  in  general,  omitting 
the  adjective  “depot”.  However,  the  1996  National  Defense  Authorization  Act  includes 
notes  from  Congress  on  Section  2464  which  explicitly  include  the  adjective  “depot”  in 
front  of  the  term  “maintenance  and  repair”  (United  States  Congress,  1996).  So  while 
Title  10  does  not  include  the  adjective  “depot”,  the  intent  of  the  law  is  clear.  Section 
2464  requires  the  government  to  maintain  a  core  capability  for  depot  maintenance  and 
repair. 

Title  10  Sec  2460  Oink  to  full  text! 

For  the  first  13  years  of  its  existence,  Section  2464  was  marred  by  confusion  and 
loopholes  that  made  its  implementation  troublesome.  By  1998,  the  year  section  2460  was 
added,  the  DoD  had  fully  embraced  a  policy  of  privatizing  depot  maintenance 
(Government  Accountability  Office,  2008).  Concepts  such  as  Contractor  Logistics 
Support  (CLS)  and  Interim  Contractor  Support  (ICS)  were  gaining  ground  and  the  DoD 
did  not  view  these  practices  as  depot  maintenance.  By  not  designating  this  work  as  depot 
maintenance,  the  DoD  was  able  to  simultaneously  comply  with  the  law  and  implement  its 
privatization  goals. 
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As  mentioned  previously,  the  law  did  not  explieitly  state  its  intent  to  speeifically 
regulate  depot  level  maintenance.  This  lack  of  specificity  resulted  in  inconsistent 
application  of  this  law.  Additionally,  the  definition  of  what  constitutes  depot 
maintenance  was  not  shared  among  all  interested  parties  and  allowed  accounting 
loopholes  for  calculating  the  mix  between  contract  and  government  work. 

Section  2460  is  important  because  it  closed  these  loopholes  by  providing  a 
definition  of  “depot-level  maintenance  and  repair”.  It  was  also  significant  because 
Congress  publicly  recognized  the  growing  reliance  on  software  within  military  systems. 
Finally,  Section  2460  states  that  depot-level  maintenance  includes  “all  aspects  of 
software  maintenance”  (Title  10  U.S.  code,  Sec.  2460,  2006  ed). 

Highlights  of  Section  2460  include  (Title  10  U.S.  code,  Sec.  2460,  2006  ed): 

•  The  definition  of  “depot- level  maintenance  and  repair”: 

o  Material  maintenance  or  repair  requiring  the  overhaul,  upgrading,  or 
rebuilding  of  parts,  assemblies,  or  subassemblies 

o  Includes  the  testing  and  reclamation  of  equipment  as  necessary 

o  Does  not  depend  on  the  source  of  funds  for  the  maintenance  or  repair  or 
the  location  at  which  the  maintenance  or  repair  is  performed 

•  Depot-level  maintenance  and  repair  includes: 

o  All  aspects  of  software  maintenance 

o  Interim  contractor  support  or  contractor  logistics  support  (or  any  similar 
contractor  support),  to  the  extent  that  such  support  is  for  the  performance 
of  services  described  in  the  definition  above 
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•  Exceptions 


o  Procurement  of  major  modifications  or  upgrades  of  weapon  systems  that 
are  designed  to  improve  program  performance.  A  major  upgrade  program 
covered  by  this  exception  could  continue  to  be  performed  by  private  or 
public  sector  activities. 

o  Procurement  of  parts  for  safety  modifications.  However,  the  term  does 
include  the  installation  of  parts  for  that  purpose. 

Significantly,  this  law  uses  hardware-centric  language  in  the  root  definition  of 
depot-level  maintenance  but  then  appends  a  statement  that  includes  software  maintenance 
within  the  scope  of  the  root  definition.  By  analogy,  if  the  repair  of  a  personal  computer  is 
formally  defined  as  the  repair  or  replacement  of  its  various  hardware  components,  it 
would  not  make  sense  to  claim  this  definition  includes  the  correction  of  software  bugs. 

Or  to  turn  the  analogy  inside  out,  if  software  maintenance  is  defined  as  writing  new  code 
to  correct  bugs  discovered  since  initial  software  release,  it  would  be  confusing  to  claim 
that  this  definition  of  maintenance  includes  hard  drive  replacement. 

The  basic  definition  of  depot-level  maintenance  in  Section  2460  seems  to  have 
been  written  with  hardware  in  mind.  A  line  including  software  maintenance  appears  to 
have  been  added  after  the  fact,  indicating  an  understanding  of  the  growing  importance  of 
software  in  military  systems  but  a  weak  grasp  of  the  unique  nature  of  software 
maintenance. 

In  summary,  Section  2460  provides  a  definition  of  “depot-level  maintenance  and 
repair”  and  states  that  depot-level  maintenance  includes  “all  aspects  of  software 
maintenance”. 
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Title  10  Sec  2466  Aink  to  full  text) 

Section  2466  requires  that  a  maximum  of  50%  of  depot-maintenance  and  repair 
workload  funds  be  used  for  non-government  contract  work.  This  portion  of  Title  10  has 
been  used  alternatively  to  encourage  or  limit  the  proportion  of  depot  funds  spent  in  the 
private  sector.  The  50%  limit  for  government  work  was  established  in  the  1998 
NDAA — a  change  from  earlier  limits  summarized  in  Figure  7.  The  Congressional  record 
of  debate  that  preceded  passage  of  the  1998  NDAA  reveals  that  the  50%  limit  was  a 
compromise  between  two  goals  in  tension:  preserving  public  sector  jobs  while  allowing 
the  DoD  the  necessary  flexibility  to  apply  sound  business  practices  in  making  source  of 
repair  decisions.  Additionally,  Section  2466  requires  the  Secretary  of  Defense  to  report 
annually  to  Congress  on  the  DoD’s  compliance  with  this  requirement  (Title  10  U.S. 

Code,  Sec.  2466,  2006  ed). 

Title  10  Sec  2470  Oink  to  full  text! 

Added  via  the  1998  NDAA,  this  section  of  Title  10  states  that  in  cases  where 
competition  is  used  to  source  depot  work,  government  depots  must  be  eligible  to 
compete.  Congress  included  this  language  because  DoD  had  at  times  excluded 
government  depots  from  competition  out  of  a  desire  to  shift  work  to  private  industry  in 
hopes  of  keeping  private  industry  viable  (Government  Accountability  Office,  1998). 

Title  10  Sec  2474  Oink  to  full  text! 

The  1998  National  Defense  Authorization  Act  that  established  Section  2460  also 
established  section  2474.  As  mentioned  previously,  section  2460  was  primarily  aimed  at 
closing  loopholes  that  the  DoD  used  to  allocate  more  depot  work  to  the  private  sector.  In 
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contrast,  Section  2474  appears  to  be  recognition  by  Congress  that  the  DoD’s  efforts  to  cut 
costs  by  privatizing  depot  maintenance  were  not  without  merit.  Section  2474  recognizes 
that  a  re-invigorated  government  depot  system  which  embraces  private  contractors  could 
provide  effective  and  cost  efficient  depot  maintenance  at  acceptable  risk  to  the 
government.  This  tension  is  relieved  through  Public-Private  Partnerships. 

Section  2474  defines  Public-Private  Partnerships  and  allows  government  depots 
to  partner  with  private  entities  that  may  then  perform  work  related  to  the  core 
competencies  of  the  government  depot. 

The  objectives  of  such  partnerships,  according  to  Section  2474,  are: 

•  Maximize  use  of  the  government  depots  capacity 

•  Reduce  cost  of  ownership  of  a  government  depot 

•  Reduce  cost  of  products  that  are  maintained  or  produced  at  the  depot 

•  Leverage  private  sector  investment  in  equipment  recapitalization  and 
promotion  of  business  ventures 

•  Foster  cooperation  between  the  armed  forces  and  private  industry. 

This  portion  of  Title  10  is  relevant  to  the  discussion  because  it  allows  and  defines 
Public-Private  Partnerships,  which  are  an  increasingly  common  tool  for  leveraging  the 
advantages  of  both  organic  and  contractor  depot  maintenance.  This  option  is  critical  to 
the  analysis  of  which  parties  should  perform  OFP  maintenance  and  development. 

Secondly,  Section  2474  requires  that  each  government  depot  be  designated  a 
Center  of  Industrial  and  Technical  Excellence  in  that  depot’s  particular  area  of  expertise, 
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effectively  requiring  the  depots  to  specialize  and  become  “recognized  leaders  in  their 
core  competencies”. 

DoD  Policy 

With  this  overview  of  Title  lO’s  direction,  an  analysis  of  the  DoD’s  policy  can 
begin.  As  government  agencies  such  as  the  GAO  highlighted  gaps  between  Title  10  and 
DoD  policy,  DoD  policy  documents  have  grown  increasingly  detailed  in  their  instructions 
for  implementation  of  Title  lO’s  maintenance  capability  requirement.  Figure  8  depicts  the 
relationship  between  DoD  policy  documents,  upstream  Title  10  sections,  and  downstream 
USAF  instructions. 
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Core  Logistics  Policy  Tree 


Figure  8.  Core  logistics  policy  tree 
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Reports  by  Government  Agencies 

Numerous  GAO  reports  and  several  CBO  reports  are  cited  in  this  research.  While 
the  GAO  was  primarily  concerned  with  adherence  to  law  and  government  insulation  from 
logistical  risks,  the  CBO  focused  on  ways  to  perform  depot  maintenance  as  cost- 
effectively  as  possible.  The  CBO  examined  the  genesis  of  the  current  depot  maintenance 
system  to  find  areas  where  it  could  be  improved,  identified  the  relevant  attributes  which 
would  make  one  sector  more  cost  effective  than  another,  and  offered  conceptual  options 
for  analyzing  workloads  and  assigning  them  to  the  different  sectors. 

From  1996  through  2009  the  GAO  was  tasked  by  various  National  Defense 
Authorization  Acts  to  report  on  DoD’s  core  capabilities  at  least  14  times.  Early  GAO 
reports  generally  dealt  with  the  growing  trend  of  privatization  in  the  DoD.  Later  GAO 
reports  focused  on  DoD  policies  related  to  the  50-50  workload  split  mandated  by  Title  10 
Section  2466.  The  most  recent  focus  of  the  GAO  has  been  on  the  DoD’s  ability  to 
identify  core  capabilities. 

GAO  reports  that  analyze  DoD’s  compliance  with  Title  10  are  listed  in  Table  1 
and  summarized  in  Appendix  E,  which  can  be  accessed  via  the  hyperlinks  in  Table  1. 
Reading  the  report  titles  alone  provides  a  cursory  overview  of  trends  in  the  public-private 
debate  over  the  last  15  years.  In  summary,  GAO  and  CBO  reports  recount  the  ongoing 
debate  between  Congress  and  the  DoD  regarding  the  intent  behind  Title  10  and  its 
validity  in  today’s  world. 
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Table  1.  GAO  reports  pertaining  to  core  depot  maintenance  capabilities 


Year 

Report  ID 

(hyperlinked  to  report) 

Title 

(hyperlinked  to  annotated  bibliography) 

1996 

GAO/T-NSIAD-96-148 

Privatization  and  the  Debate  Over  the  Public-Private  Mix 

GAO/NSIAD-96-165 

DoD's  Policy  Report  Leaves  Future  Role  of  Depot  Systenn 
Uncertain 

GAO/NSIAD-96-166 

More  Connprehensive  and  Consistent  Workload  Data 

Needed  for  Decision  nnakers 

1997 

GAO/T-NSIAD-97-112 

Uncertainties  and  Challenges  DoD  Faces  in  Restructuring  Its 
Depot  Maintenance  Progrann 

1998 

GAO/NSIAD-98-8 

DoD  Shifting  More  Workload  for  New  Weapon  Systenns  to 
the  Private  Sector 

2000 

GAO/T-NSIAD-00-112 

Air  Force  Faces  Challenges  in  Managing  to  50-50  Ceiling 

GAO/NSIAD-00-115 

Air  Force  Report  on  Contractor  Support  is  Narrowly  Focused 

GAO/NSIAD-00-152R 

Air  Force  Waiver  to  U.S.C  2466 

2001 

GAO-02-105 

Actions  Needed  to  Overconne  Capability  Gaps  in  the  Public 
Depot  Systenn 

2006 

GAO-06-839 

DoD  Should  Strengthen  Policies  for  Assessing  Technical  Data 
Needs  to  Support  Weapon  Systenns 

2008 

GAO-08-572T 

DoD  Needs  to  Reexannine  Its  Extensive  Reliance  on 
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The  Push  for  Private  Sector  Sustainment 


Several  GAO  reports  offer  insight  into  the  friction  between  the  DoD’s  desires  for 
greater  flexibility  afforded  by  privatization  and  Congress’s  desire  to  maintain  strong  core 
capabilities  at  government  depots.  The  GAO  moderated  debate  regarding  privatization 
essentially  began  in  1996  when  the  DoD  was  looking  to  transform  itself  both  in  combat 
and  logistic  capability  after  the  Cold  War.  As  the  number  of  major  acquisition  programs 
decreased,  the  DoD  became  concerned  the  industrial  base  could  not  be  maintained  and 
saw  depot  maintenance  as  a  way  to  keep  private  industry  viable  (Congressional  Budget 
Office,  1995).  Additionally,  proponents  of  privatization  argued  the  private  sector  could 
perform  depot  maintenance  with  greater  cost  effectiveness  compared  to  the  public  sector. 

The  DoD  policy  shift  toward  privatization  in  the  mid  1990s  was  highlighted  in  the 
1996  GAO  report  DoD ’s  Policy  Report  Leaves  Future  Role  of  Depot  System  Uncertain. 
Key  points  included: 

•  A  desire  for  minimum  core  requirements. 

•  Redefining  core  requirements  to  allow  for  privatizing  mission  essential 
requirements  previously  defined  as  core. 

•  Limiting  public  depots  from  competing  with  the  private  sector  for  non-core 
workloads. 

•  Providing  a  preference  for  privatizing  depot  maintenance  for  new  systems. 

In  contrast  to  the  GAO’s  characterization,  the  DoD  was  not  making  unsupportable 
policy  decisions.  The  1995  report  of  the  Congressionally  established  Commission  on 
Roles  and  Missions  of  the  Armed  Forces  completely  rejected  the  concept  of  core  logistics 
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capabilities  and  .  .recommended  outsourcing  depot  maintenance  for  all  equipment, 


including  all  depot  maintenance  for  new  weapon  systems  to  third-party  providers” 
(Withers,  2000).  This  view  was  shared  by  the  Defense  Science  Board,  a  civilian  advisory 
panel  to  the  DoD,  which  concluded  “that  DoD  only  engage  in  direct  warfighting  policy, 
decision  making,  and  oversight  activities  and  that  all  other  activities,  especially  depot 
maintenance,  be  outsourced  to  third-party  providers”  (Withers,  2000). 

A  February  2000  article  in  Army  Sustainment  (the  Army’s  professional  journal  for 
the  sustainment  warfighting  function)  summarizes  the  trend  toward  privatization  in  this 
way: 


Acquisition  program  managers  decide  on  the  source  of  repair  for  their 
weapon  systems.  Their  decisions  drive  billions  of  dollars  in  support  costs 
and  affect  near-term  investments  in  support  equipment,  repair  parts, 
training,  and  technical  data  (engineering  drawings  and  technical  manuals). 
In  the  recent  past,  acquisition  program  managers  selected  organic  DoD 
maintenance  depots  for  core  equipment.  However,  it  became  obvious  that 
commercial  sources  could  execute  depot  maintenance  work  that  exceeded 
organic  capacities  and  capabilities;  they  also  could  do  the  work  when 
DoD's  capability  had  not  yet  been  established.  The  result  has  been  a  trend 
toward  greater  private  sector  involvement  in  depot-level  maintenance. 
Approximately  10  years  ago,  organic  depots  performed  the  maintenance 
for  75  percent  of  all  equipment.  Today,  the  private  sector  provides  40  to 
50  percent  of  depot-level  maintenance.  (Withers,  2000) 


An  additional  DoD  policy  change  in  the  mid  1990s  was  to  move  source  of  repair 
decision  authority  from  the  service  logistics  chief  to  the  program  manager,  which 
recognized  the  role  of  sustainment  in  the  total  lifecycle  of  a  system  (Government 
Accountability  Office,  1996).  However,  this  shift  may  have  forfeited  the  knowledge  and 
expertise  logistics  chiefs  contribute  to  the  sustainment  of  the  depots  themselves. 
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In  contrast  to  proponents  of  privatization,  the  GAO  coneluded  in  its  report  titled 
Privatization  and  the  Debate  Over  the  Public-Private  Mix  that  this  shift  toward 
privatization  in  DoD  policy  might  exacerbate  existing  excess  capaeity  problems  at 
government  depots,  inereasing  inefficieney  due  to  an  underutilized  depot  maintenanee 
structure  (Government  Aeeountability  Office,  1996).  Additionally,  the  GAO  found  DoD 
poliey  to  be  inconsistent  with  eongressional  guidanee  in  the  area  of  publie-private 
competitions  for  non-core  workloads  (Government  Aeeountability  Offiee,  1996). 

Another  significant  finding  by  the  GAO  was  the  impact  of  privatization  on  the 
ability  of  publie  depots  to  maintain  capability  in  the  area  of  new  technologies.  The  GAO 
report  titled  Air  Force  Report  on  Contractor  Support  is  Narrowly  Focused  highlighted 
this  faet  by  ineluding  a  memorandum  from  the  Ogden  Air  Logistics  Center  to  Air  Foree 
Materiel  Command  dated  9  Feb  2000  whieh  stated: 


Infusion  of  new  technology  workloads  from  new  weapon  systems  is 
essential  to  maintain  eore.  Therefore  the  future  of  the  [air  logistics  center] 
is  eontingent  upon  acquiring  workloads  in  each  technical  repair  center  that 
will  continue  to  provide  a  viable  organie  source  of  repair  for  the  using 
eommands.  If  an  [air  logistics  center]  is  determined  core  or  best  value  in  a 
partieular  technology,  then  any  new  weapon  system  aequired  that  has  the 
associated  technology  should  have  the  respeetive  core  alloeation  from  day 
one  of  the  sustainment  life  cycle.  The  eore  determination  is  weighted 
heavily  towards  older  high  surge  workloads.  Depots  are  provided  new 
workloads  often  only  after  the  original  equipment  manufacturer  loses 
interest.  (Government  Aeeountability  Offiee,  2000) 


As  an  example  of  the  DoD  policy  shift  the  GAO  reported  that  by  1997,  52  pereent 
of  the  new  aequisition  programs  studied  were  either  seleeting  or  leaning  towards  private 
seetor  depot  maintenanee  eompared  to  16  percent  seleeting  or  leaning  towards  publie 
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sector  depots  (Government  Accountability  Office,  1998).  Uncertainty  with  the  policy 
created  confusion  and  programs  such  as  the  C-17  delayed  source  of  repair  decisions  for  at 
least  six  years  to  allow  logistics  policy  to  stabilize  (Government  Accountability  Office, 
1998).  Figure  9  summarizes  this  mid  1990s  trend  in  program  offices  delaying  source  of 
repair  decisions  (Government  Accountability  Office,  1997). 


Sustainment  Choices  for  Major  Systems  (1997) 


System 

Leaning  to 
Organic 

Undecided/ 

Deferred 

Leaning  to 
Contract 

Army 

Apache  Longbow 

X 

Black  Hawk 

X 

Javelin 

X 

JSTARS  GSM 

X 

Paladin 

X 

Navy 

F/A-18E/F 

X 

Seawolf 

X 

T406  engine 

X 

V-22  Osprey 

X 

Air  Force 

AC-130U  Gunship 

X 

B-IBCMUP 

X 

C-17 

X 

F-117  Engine 

X 

F-22 

X 

JASSM 

X 

Figure  9.  Major  acquisition  program  source  of  repair  decisions  -  1997 


The  change  in  source  of  repair  decision  authority  and  the  flux  in  policy  was 
further  evidenced  by  nearly  76  percent  of  program  managers  indicating  they  did  not  plan 
to  make  core  designations  or  were  uncertain  about  how  or  whether  to  consider  core. 
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Some  program  managers  responded  that  they  were  not  sure  what  the  term  “core”  meant 
(Government  Accountability  Office,  1998). 


Congress  clearly  did  not  agree  with  DoD  policy  in  its  entirety  and  used  the 
1998  NDAA  to  create  Title  10  section  2460  which  established  a  definition  of  depot-level 
maintenance.  The  definition  included  “software  maintenance”  as  depot  level 
maintenance.  Congress  also  amended  Section  2464  by  adding  the  requirement  that  the 
DoD-maintained  core  logistics  capability  be  government  owned  and  operated.  The  GAO 
offered  its  own  expanded  definition  of  depot  maintenance  in  its  report  titled  Uncertainties 
and  Challenges  DoD  Faces  in  Restructuring  Its  Depot  Maintenance  Program,  which 
reads: 


Depot  maintenance  is  a  vast  undertaking  that  requires  extensive  shop 
facilities,  specialized  equipment,  and  highly  skilled  technical  and 
engineering  personnel  to  perform  major  overhauls  of  weapon  systems  and 
equipment,  to  completely  rebuild  parts  and  end  items,  to  modify  systems 
and  equipment  by  applying  new  or  improved  components,  to  manufacture 
parts  unavailable  from  the  private  sector,  and  to  program  the  software  that 
is  an  integral  part  of  today’s  complex  weapon  systems.  (Government 
Accountability  Office,  1997) 


The  basis  for  much  of  the  debate  was  the  DoD  assertion  that  it  could  reduce 
maintenance  costs  by  20-40  percent  by  outsourcing  depot  maintenance — a  savings  of 
billions  of  dollars  (Congressional  Budget  Office,  1995).  The  GAO  found  inconsistencies 
in  the  cost  comparisons  used  by  the  DoD,  which  lead  the  GAO  to  a  more  pessimistic 
expectation  of  cost  savings  associated  with  privatization.  The  GAO  argued  the  DoD  used 
outsourcing  of  vehicle  maintenance  and  food  services  as  the  basis  of  cost  savings.  The 
GAO  analyzed  what  it  considered  to  be  more  similar  private-public  program 
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competitions  and  came  to  a  different  eonclusion:  public  depots  were  as  eompetitive  as  the 
private  sector  and  in  many  cases  were  the  more  cost  effective  option  (Government 
Accountability  Offiee,  1996): 

•  67%  of  competitions  were  won  by  the  DoD  with  the  average  bid  40% 
lower  than  the  elosest  eompetitor. 

•  23%  of  the  programs  showed  no  private  bids  were  offered  and  35% 
ineluded  only  one  private  bid. 

•  62%  of  items  repaired  by  both  private  and  publie  depots  were  maintained 
less  expensively  in  the  publie  sector. 

While  Congress  clearly  was  not  comfortable  with  the  DoD’s  preference  for 
private  depots,  they  did  reeognize  a  role  for  private  depots  in  the  overall  DoD 
sustainment  plan.  This  was  refleeted  in  the  1998  NDAA  which  amended  Title  10 
Seetion  2466  to  allow  the  DoD  use  of  up  to  50  pereent  of  depot  maintenanee  funds  for 
private  sector  work  (up  from  40%  previously). 

Title  10  Changes  That  Allowed  More  Private  Sustainment 

In  its  1995  report  titled  Public  and  Private  Roles  in  Maintaining  Military 
Equipment  at  the  Depot  Level  the  CBO  noted  that  in  the  Air  Force  the  division  between 
private  development  and  publie  sustainment  evolved  primarily  out  of  neeessity.  The 
aviation  industry  in  the  1940’s  was  in  the  proeess  of  increasing  its  capaeity  and  eould  not 
yet  handle  both  produetion  and  maintenance  funetions  simultaneously.  The  publie  depot 
filled  the  eapacity  gap  in  the  private  sector.  In  the  years  after  the  war  the  Air  Force 
began  to  slowly  move  towards  contract  depot  maintenanee  due  to  a  laek  of  facilities  and 
skilled  maintainers  in  the  publie  sector  (Congressional  Budget  Offiee,  1995). 
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Prior  to  1982  there  was  no  legal  limit  on  the  amount  of  work  done  in  the  private 
seetor.  This  researeh  team  surmises  a  limit  did  not  exist  because  nearly  all  work  was 
voluntarily  conducted  within  public  depots,  although  this  is  not  explicitly  stated.  Then  by 
1982,  the  DoD  directed  that  not  more  than  70  percent  of  work  be  done  in  public  depots 
(Government  Accountability  Office,  2008).  The  rationale  for  this  policy  is  not  clear,  but 
it  is  reasonable  to  assume  the  DoD  was  attempting  to  create  competition  for  work  to  help 
decrease  maintenance  costs. 

The  limit  changed  again  in  1991  (Government  Accountability  Office,  2008).  But 
this  time  instead  of  placing  a  limit  on  the  government’s  share  of  depot  work,  Congress 
placed  a  minimum  on  the  government’s  share  of  depot  work.  Title  10  was  amended  to 
include  a  60  percent  organic  workload  floor  -  presumably  in  response  to  an  increasing 
shift  towards  privatized  maintenance.  By  1996,  DoD  policy  had  completely  shifted 
towards  privatization.  Complying  with  the  60  percent  government  workload  minimum 
became  increasingly  difficult  (Government  Accountability  Office,  2008). 

By  1997,  the  Air  Force  was  not  only  unable  to  meet  the  60/40  mandate,  but  could 
not  even  reach  50  percent  government  workload  (Government  Accountability  Office, 
1996).  The  GAO  projected  that  by  2001  the  Air  Force  would  only  be  able  to  achieve  a 
46/54  split,  with  the  majority  of  work  funds  allocated  to  private  industry.  The  reasons 
cited  for  the  low  percentage  of  public  sector  funding  were  a  combination  of  DoD  policy 
and  closing  of  multiple  government  depots  by  the  1995  Base  Realignment  and  Closure 
(BRAC)  process  (Government  Accountability  Office,  1996). 
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The  DoD  then  ealled  for  a  complete  repeal  of  the  60/40  requirement  arguing  it 
was  arbitrary  and  prohibited  sound  business  practices.  The  GAO  disagreed,  contending 
that  repealing  the  60/40  rule  would  encourage  further  privatization  which  could  result  in 
higher  depot  maintenance  costs  by  eliminating  competition  from  the  public  sector,  and 
increased  readiness  risks  due  to  mission-essential  work  being  transferred  to  the  private 
sector  (Government  Accountability  Office,  1996).  Congress,  in  an  apparent  compromise, 
lowered  the  minimum  public  share  of  depot  maintenance  funds  to  50  percent.  These 
changes  in  the  legal  ceilings  and  floors  on  government  depot  work  are  depicted  in  Figure 
10. 


Workload  Distribution  Required  by  Law 
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Figure  10.  Workload  distribution  required  by  law. 
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The  shift  towards  the  private  sector  continued,  however.  Figure  1 1  depicts  the 
proportion  of  Air  Force  workload  performed  by  government  and  private  sectors  during 
this  period  of  flux  in  Title  10  workload  funding  limits.  Note  that  by  1999  the  Air  Force 
consistently  failed  to  reach  the  requirement  for  a  minimum  50  percent  government 
allocation  of  workload  funds. 


Figure  11.  Proportion  of  depot  work  in  public  and  private  sectors 


In  summary,  the  1980s  and  1990s  saw  significant  swings  in  emphasis  between 
public  and  private  depot  work.  The  changing  emphasis  undoubtedly  impacted  key 
lifecycle  decisions  of  many  programs  as  they  elected  to  wait  for  the  policy  to  stabilize 
before  making  long-term  source  of  repair  decisions. 
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Ridine  the  Sine  Wave:  F-22  Loeistics  Plannine 

As  a  brief  case  study,  the  F-22  provides  a  good  example  of  a  program  caught 
between  shifting  policy  and  the  need  to  plan  for  the  future.  F-22  flight  testing  began  in 
the  mid  1990s  and  plans  were  being  developed  for  long-term  depot  level  maintenance. 
During  this  time  the  Air  Force  Chief  of  Staff  directed  the  F-22  program  office  to  consider 
private  logistics  support  as  a  means  for  cutting  cost  (Government  Accountability  Office, 
1997).  According  to  a  2009  interview  with  the  F-22  program  office,  as  a  result  of  the 
push  for  private  sustainment  the  F-22  program  in  the  mid-1990s  halted  government  depot 
preparations  and  stopped  generating  Logistics  Support  Analysis  (LSA)  data. 

By  2002,  the  pendulum  had  swung  back  the  other  way,  and  AFMC  designated  the 
depot  maintenance  of  most  F-22  subsystems  as  a  core  organic  logistics  capability  in 
accordance  with  Title  10  (F-22  Acquistion  Strategy  Panel,  2007).  The  F-22  was  declared 
to  have  Initial  Operational  Capability  (IOC)  in  Dec  2005  and  the  four  year  deadline  for 
transition  from  interim  contractor  logistics  support  to  organic  sustainment  loomed. 

As  evidenced  by  the  F-22,  the  development  time  of  military  aircraft  is  on  the  rise. 
F-22  IOC  was  declared  14  years  after  the  1991  down-select  contract  award  to  Lockheed. 
Policy  changes  early  in  this  period  prevented  early  depot  maintenance  planning,  causing 
an  expensive  catch-up  game  in  the  early  to  mid  2000’s.  In  addition  to  changes  in  the 
legally  required  division  of  labor  between  public  and  private  sectors,  confusion  existed 
over  the  identification  of  core  capabilities. 
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What  Are  Core  Capabilities? 

The  central  hurdle  for  the  DoD  in  the  late  1990s  was  establishing  clear  guidance 
on  the  identification  of  core  capabilities  for  depot  maintenance  (Government 
Accountability  Office,  2001).  There  lacked  a  systematic  and  consistent  approach  to 
identifying  which  logistic  capabilities  should  be  maintained  in  the  public  sector  and 
which  capabilities  are  better  suited  to  competition  in  the  private  sector.  As  a  result, 
processes  varied  from  service  to  service.  Some  included  software  while  others  excluded 
it,  and  workload  calculations  required  by  the  60/40  and  later  50/50  laws  were  not 
consistent  (Government  Accountability  Office,  2001). 

In  a  2001  report  the  GAO  reported  that  government  depots  were  ill-equipped  to 
maintain  their  core  capabilities  due  to  a  lack  of  long-term  strategic  depot  planning  on  the 
part  of  the  DoD  (Government  Accountability  Office,  2001).  A  high  average  age  in  the 
workforce,  aging  equipment,  and  a  lack  of  capital  investment  called  into  question  the 
long  term  viability  of  government  depots. 

Today  the  government  depots  are  fewer  in  number  but  still  hard  at  work.  And  yet 
the  challenge  of  identifying  core  capabilities  still  exists.  Software  maintenance  is  a  clear 
example  of  the  lack  of  standardization  and  direction  across  the  DoD.  The  Navy  continued 
to  exclude  software  from  core  requirements  into  2009  while  the  Air  Force  included 
software  (AFMC/A4DC,  2009).  In  2009  a  GAO  report  highlighted  the  Navy’s  exclusion 
of  software  from  core  workload  calculations,  and  the  Navy  began  the  transition  toward 
including  software  maintenance  as  a  core  capability  (Government  Accountability  Office, 
2009). 
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“Like”  Workloads  in  Achievine  Core  Capability 

An  additional  area  of  concern  is  the  DoD’s  use  of  “like”  workloads  to  satisfy  core 
logistics  requirements.  For  example,  the  DoD  used  workload  on  the  C-141  and  C-5  to 
satisfy  core  capability  workload  on  the  C-17  (Government  Accountability  Office,  2001). 
The  GAO  did  not  believe  this  practice  truly  established  a  core  capability  nor  met  the 
intent  of  the  governing  law.  The  DoD’s  response  was  to  provide  an  analogy  of  an  auto 
mechanic  who  can  perform  work  on  Chrysler,  Ford,  and  General  Motors  products,  if  the 
mechanic  has  tools,  facilities,  and  knowledge.  They  asserted  the  skills,  facilities,  and 
knowledge  are  transferable  and  that  the  same  holds  true  within  the  DoD.  The  policy  of 
using  like  work  continues  within  the  Air  Force  (Government  Accountability  Office, 
2001). 

Law  and  Policy  Summary 

The  general  trend  in  division  of  depot  maintenance  workload  between  the 
government  and  private  industry  from  the  mid  1 990s  to  the  present  is  from  public 
sustainment  to  private  sustainment.  Two  foundational  requirements  of  Title  10 
established  in  1985  continue  to  be  challenging  to  implement. 

First,  the  DoD  has  been  slow  to  clearly  identify  its  core  logistics  capabilities. 
Services  have  interpreted  law  and  policy  differently,  particularly  in  the  area  of  software 
maintenance.  The  lack  of  clear  definitions  in  policy  documents  is  central  to  this  problem. 

Second,  Title  10  has  incrementally  decreased  the  minimum  share  of  depot 
workload  funds  that  must  be  allocated  to  government  depots.  Yet  the  Air  Force  has 
struggled  to  meet  the  legal  minimum  as  depot  workload  was  increasingly  allocated  to  the 
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private  sector  during  the  1990s.  The  debate  over  the  relative  advantages  of  public  or 
private  depots  continues,  and  the  services  are  increasingly  being  held  accountable  for 
Title  10  compliance. 

With  this  survey  of  law  and  policy  history  complete,  it  is  time  to  examine  the 
current  state  of  affairs.  How  is  core  policy  implemented  today?  First,  the  relevance  of 
Title  lO’s  core  logistics  requirement  in  today’s  environment  is  examined.  Next,  the 
current  source  of  repair  decision  process  is  explained  by  means  of  functional  and  process 
models. 
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III.  Relevance  of  Title  lO’s  Organic  Maintenance  Requirement 


Introduction:  Examining  Intent? 

Laws  are  written  for  speeifie  reasons  in  a  specifie  context.  If  any  law  is  to  remain 
relevant  and  applicable  into  the  future,  it  must  be  periodically  assessed  and  changed  when 
and  where  needed.  The  motive  of  an  existing  law  provides  the  necessary  context  for 
performing  such  an  assessment.  Therefore,  before  proposing  changes  to  the  text  of  the 
Title  10  law  or  changes  to  policies  that  implement  the  law,  examining  the  motives  behind 
the  law  is  critical. 

Research  methods  employed  in  this  examination  included  an  analysis  of  Title  10 
itself,  a  review  of  congressional  debate  preceding  passage  of  the  law  and  its  changes,  and 
a  study  of  reports  on  this  issue  published  by  the  Congressional  Budget  Office  and  the 
Government  Accountability  Office. 

The  Intent  of  Title  10 

Why  does  Title  10  Section  2464  require  the  government  to  maintain  a  capability 
to  maintain  and  repair  military  systems  used  in  our  major  war  scenarios?  Answering  this 
question  is  vital  in  determining  the  scope  of  the  law’s  application.  A  single  explicit 
reason  is  provided  in  the  text  of  the  law  itself  (emphasis  added): 

It  is  essential  for  the  national  defense  that  the  Department  of  Defense 
maintain  a  core  logistics  capability  that  is  Government-owned  and 
Government-operated  (including  Government  personnel  and  Government- 
owned  and  Government-operated  equipment  and  facilities)  to  ensure  a 
ready  and  controlled  source  of  technical  competence  and  resources 
necessary  to  ensure  effective  and  timely  response  to  a  mobilization, 
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national  defense  contingency  situations,  and  other  emergency 
requirements.  (Title  10  U.S.  Code,  Sec.  2464,  2006  ed) 


The  explicit  motivation  is  to  ensure  a  ready  and  controlled  maintenance 
capability.  The  government  does  not  have  control  over  the  private  sector  and  can 
therefore  not  ensure  that  industry  is  ready  to  perform  the  sustainment  work  needed  in 
time  of  war.  While  this  makes  good  sense  on  the  surface,  it  generates  several  more 
questions. 


Does  Title  10  Specifically  Refer  to  Depot  Level  Maintenance  Only? 

While  the  language  of  Title  10  does  not  include  the  adjective  “depof’,  the 
congressional  record  reveals  that  depot  maintenance  was  in  mind  here.  For  example, 
PUBLIC  LAW  104-106 — FEB.  10,  1996,  which  constituted  the  1996  National  Defense 
Authorization  Act,  includes  the  following  language  (italics  added): 


(a)  FINDINGS. — Congress  makes  the  following  findings: 

(1)  The  Department  of  Defense  does  not  have  a  comprehensive 
policy  regarding  the  performance  of  depot-level  maintenance  and 
repair  of  military  equipment. 

(2)  The  absence  of  such  a  policy  has  caused  the  Congress  to 
establish  guidelines  for  the  performance  of  such  functions. 

(3)  It  is  essential  to  the  national  security  of  the  United  States  that 
the  Department  of  Defense  maintain  an  organic  capability  within 
the  department,  including  skilled  personnel,  technical 
competencies,  equipment,  and  facilities,  to  perform  depot-level 
maintenance  and  repair  of  military  equipment  in  order  to  ensure 
that  the  Armed  Forces  of  the  United  States  are  able  to  meet 
training,  operational,  mobilization,  and  emergency  requirements 
without  impediment. 
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(4)  The  organic  capability  of  the  Department  of  Defense  to 
perform  depot-level  maintenance  and  repair  of  military  equipment 
must  satisfy  known  and  anticipated  core  maintenance  and  repair 
requirements  across  the  full  range  of  peacetime  and  wartime 
scenarios.  (National  Defense  Authorization  Act  for  1996,  1996) 


The  Congressional  record  clearly  states  that  the  context  of  Section  2464  is  depot- 
level  maintenance.  Why  the  law  itself  does  not  include  the  adjective  “depot”  is  unknown. 
All  parties  interviewed  as  part  of  this  research  considered  the  Title  10  core  maintenance 
capability  requirement  to  be  in  the  context  of  depot-level  maintenance  only.  Perhaps  the 
ambiguity  in  the  law  does  not  cause  interpretation  problems  because  field/unit  level 
maintenance  is  typically  organic,  and  the  lines  between  intermediate-level  maintenance 
and  the  other  two  levels  are  fast  disappearing. 

The  other  sections  in  Title  10  clearly  show  that  depot-level  maintenance  is  the 
context  of  Section  2464,  and  so  does  DoD  policy.  DODI  4151.18,  the  foundational  DoD 
instruction  which  implements  Title  10  Section  2464,  specifically  applies  Section  2464  to 
depot  maintenance. 

It  is  DoD  policy  that...  Initial  maintenance  programs  shall...  Identify  depot 
maintenance  core  capability  requirements,  as  required  by  reference  (e) 

[Section  2464  of  title  10,  United  States  Code]  (italics  added)  (DODD 
4151.18  Maintenance  of  Miltary  Materiel,  2004) 

In  short,  DoD  policy  references  Section  2464  as  requiring  the  DoD  to  identify 
depot  maintenance  core  capability  requirements,  while  Section  2464  does  not  use  the 
term  “depot”  at  all.  Because  DoD  policy  sets  the  direction  for  Air  Force’s  regulations,  the 
designation  of  workloads  as  “core”  and  the  calculation  of  labor  hours  required  to 
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maintain  a  core  logistics  capability  are  therefore  solely  in  the  eontext  of  depot 
maintenance. 

Is  Reliance  On  the  Private  Sector  Too  Risky? 

Requiring  the  government  to  maintain  a  ready  and  controlled  maintenanee 
capability  implies  it  is  too  risky  to  rely  on  the  private  sector  for  this  work  during  war  or 
contingency  operations  for  a  variety  of  reasons:  private  companies  ean  fail,  their 
employees  may  go  on  strike,  or  the  profit  motive  may  pull  a  eontractor’s  attention  in 
direetions  other  than  that  of  sustaining  existing  military  systems. 

In  the  1990’s,  the  CBO  eonducted  at  least  two  reviews  of  the  role  of  private 
depots  in  the  maintenanee  of  military  systems.  The  analysis  foeused  on  relevance  of 
publie  sector  depots  in  the  post-eold  war  era,  the  relevant  attributes  of  eaeh  sector,  and 
the  eost  effeetiveness  of  various  depot  options.  The  following  analysis  is  a  digestion  of 
CBO  reports. 

In  the  mid- 1 990 ’s,  a  debate  between  Congress  and  DoD  eonceming  the  roles  of 
government  and  private  seetors,  with  regard  to  depot  maintenanee,  was  building.  The 
reassessment  of  industry’s  role  in  depot  level  maintenanee  of  military  materiel  was  a 
contentious  issue.  In  the  wake  of  the  Cold  War,  the  premise  that  the  DoD  required  a 
“ready  and  eontrolled”  organic  source  of  maintenanee  was  ealled  into  question.  The  DoD 
argued  that  “the  depots  were  neeessary  to  proteet  against  the  risk  that  contractors  might 
be  either  unable  or  unwilling  to  respond  immediately  to  DoD's  requirements  for 
maintenance  during  a  war’’  (Congressional  Budget  Office,  1995).  The  DoD  would  later 
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reverse  their  stanee  on  this  issue  and  ehampion  a  greater  role  for  private  depots  in  the 
sustainment  of  military  systems. 


But  the  shift  in  policy  in  the  1990’s  towards  a  two  major  regional  war  scenario 
may  have  invalidated  the  Cold  War  premises.  In  fact,  the  CBO  postulated  that  in  these 
types  of  wars  (such  as  OPERATION  DESERT  STORM),  the  duration  of  the  conflict 
would  be  sufficiently  short  that  the  bulk  of  system  repairs  would  actually  occur  after 
hostilities  terminated: 

The  risks  of  using  private-sector  contractors  might  be  less  severe  in  the 
regional  conflicts  for  which  the  military  now  plans  than  they  were  in  the 
Cold  War  scenarios.  Depot-level  maintenance  during  relatively  brief 
regional  conflicts  would  focus  primarily  on  repairing  components.  The 
surge  in  maintenance  on  major  end  items  would  not  reach  its  peak  until 
the  conflicts  were  over  and  DoD  could  return  the  damaged  equipment  to 
the  United  States.  (Congressional  Budget  Office,  1995) 


Additionally,  the  CBO  pointed  out  that,  unlike  World  War  II  or  Cold  War 
scenarios,  today’s  national  industrial  base  would  not  have  to  fully  mobilize  to  support 
wartime  production  and  would  therefore  have  capacity  to  support  system  maintenance. 

As  components  become  more  reliable  and  the  size  of  maintenance 
workloads  declines,  the  services  must  increasingly  balance  the  risk  of 
relying  on  contractors  for  repairs  against  the  cost  of  duplicating  the 
capabilities  of  those  contractors  in  public  depots.  The  core  method,  which 
neglects  costs  and  assumes  that  private  maintenance  is  always  too  risky 
for  mission  essential  equipment,  provides  no  guidance  about  how  to  make 
those  judgments.  (Congressional  Budget  Office,  1995) 

Since  the  CBO  made  this  assessment,  the  environment  has  changed  more  as  has 
begun  to  move  away  from  the  two-front  major  war  paradigm  to  a  more  flexible 
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engagement  scenario  with  a  greater  variety  of  enemies  using  an  increasing  variety  of 
means.  The  draft  2010  Quadrennial  Defense  Review  abandoned  the  two  major  theatre 
war  strategy.  While  the  final  version  reinstated  the  two  theatre  strategy,  DoD’s  strategy 
expanded  to  reflect  our  current  environment: 


In  the  mid-  to  long  term,  U.S.  military  forces  must  plan  and  prepare  to 
prevail  in  a  broad  range  of  operations  that  may  occur  in  multiple  theaters 
in  overlapping  time  frames.  This  includes  maintaining  the  ability  to 
prevail  against  two  capable  nation-state  aggressors,  but  we  must  take 
seriously  the  need  to  plan  for  the  broadest  possible  range  of  operations- 
from  homeland  defense  and  defense  support  to  civil  authorities,  to 
deterrence  and  preparedness  missions-occurring  in  multiple  and 
unpredictable  combinations...  (Quadrennial  Defense  Review  Report, 

2010) 

This  informs  a  related  question:  if  the  government  is  required  to  maintain  the 
capability  to  perform  depot  maintenance,  what  situations  would  require  the  government 
to  exercise  its  capability  and  actually  perform  the  maintenance  and  repair?  In  other 
words,  what  would  the  war  or  contingency  look  like  and  how  would  it  differ  from 
peacetime?  Is  there  today  a  distinction  between  wartime  and  peacetime? 

War  and  Peace:  Blurring  the  Lines 

The  calculations  used  to  determine  the  amount  of  work  required  to  maintain  a 
core  capability  are  built  on  the  premise  that  during  times  of  war  a  depot  will  be  required 
to  surge  to  higher  workloads  to  meet  increased  demand.  The  expected  increased 
workload  during  times  of  war  is  a  key  component  of  the  perceived  risk  of  privatizing 
mission  essential  workloads.  The  fear  is  the  government  will  have  no  power  to  require  a 
contractor  to  increase  their  output.  These  fears  appear  to  be  unfounded  in  the  context  of 
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modem  wars,  however.  Figure  12  eharts  the  workload  in  Navy  aviation  preceding  and 
following  the  1991  Gulf  War  (Congressional  Budget  Office,  1995).  The  graph  shows  a 
sharp  increase  in  workload  during  the  OPERATION  DESERT  SHIELD  portion  of  the 
conflict  with  a  sharp  decrease  in  work  in  the  period  leading  up  to  the  war  itself  Overall, 
the  average  workload  was  not  significantly  affected  by  this  conflict  compared  to 
peacetime  workloads. 


Workload  in  Navy  Aviation  Depots  1989-1993 
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SOURCE;  Congressional  Budget  Office  based  on  data  from  the  Navy  used  in  John  D.  Keenan  and  others,  Issues  Concerning  Public  and 
Private  Provision  of  Depot  Maintenance,  CRM  94-65  (Alexandria.  Va.:  Center  for  Naval  Analyses,  April  1994). 

Figure  12.  Workload  (Direct  Labor  Hours)  in  Navy  aviation  depots,  October  1989  to  July  1993 

Following  the  US  liberation  of  Kuwait  in  1991,  military  systems  were  used 
around  the  clock  during  10  years  of  no-fly  zone  enforcement  over  Iraq.  OPERATION 
ENDURING  FREEDOM  commenced  in  2001  and  continues  to  this  day  with  every 
branch  of  the  US  military  actively  engaged.  Military  intervention  in  Somalia  and  the 
1999  air  war  in  Yugoslavia  are  further  examples  of  military  activity  in  the  last  two 
decades.  Since  the  end  of  the  Cold  War  20  years  ago,  our  Armed  Forces  and  their 
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systems  have  been  engaged  around  the  world.  A  recent  speaker  at  a  conference  on  the 
topic  of  war  and  peace  summarized  the  new  landscape  as  follows: 


Periods  of  peace  and  war  therefore  have  come  to  be  representative  of 
strong  nations  or  unified  blocs  of  state  power.  Seldom  has  there  been  a 
threat  that  operated  well  outside  the  parameters  of  the  system.  The  rise  of 
A1  Qaeda  and  the  response  by  the  United  States  is  that  it  is  a  fundamental 
break  with  that  historical  past.  Although  currently  the  United  States  and  its 
allies  are  involved  in  a  global  war  against  terrorism  that  maintains  two 
active  military  fronts  and  a  constant  state  of  awareness,  there  has  not  been 
an  official  declaration  of  war  by  the  United  States  Congress.  The  lines  of 
war  and  peace  blur  further  as  the  military  services  of  the  U.S.  and  its  allies 
continue  to  conduct  combat  operations. . .  (Kalic,  2010) 


Gone  is  the  Cold  War  paradigm  of  protracted  large-scale  conflict.  Today’s  wars 
are  fundamentally  different:  shorter,  more  frequent,  overlapping,  with  diverse  and 
difficult  to  identify  adversaries.  An  unpredictable  fast-changing  environment  demands  a 
more  flexible  law — a  law  that  is  not  built  on  clear  transitions  from  peacetime  to  wartime 
with  associated  surges  in  depot  workload.  Over  the  last  20  years,  both  the  military  and 
industry  have  been  continually  engaged  in  waging  and  supporting  military  conflicts. 
Additionally,  reliance  on  the  private  sector  extends  beyond  depot  maintenance.  Private 
industry  is  the  origin  of  the  parts  supply  chain. 

Private  Sector  Supply  Chain 

Aside  from  relying  on  contractors  for  depot  maintenance,  is  it  realistic  for  the 
DoD  to  not  rely  on  the  private  sector  for  sustainment  tasks  such  as  supplying  new  parts? 
If  the  motive  for  Title  lO’s  core  capability  requirement  is  to  shield  the  government  from 
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the  risk  of  relying  on  private  seetor  maintenance,  how  can  this  be  accomplished  when 
many  of  the  spare  parts  used  in  sustainment  come  from  private  industry? 

. .  .at  least  since  World  War  II,  DoD  has  depended  on  private  production  to 
supply  virtually  all  of  the  consumable  goods  (for  example,  food,  clothing, 
fuel)  and  most  of  the  spare  parts  and  weapon  systems  that  it  uses. 

(Congressional  Budget  Office,  1995) 

As  the  CBO  stated,  the  military  relies  heavily  on  private  industry  for  spare  parts. 
And  this  is  especially  true  in  today’s  high-tech  systems  where  the  military  depot  may  be 
able  to  repair  a  Line-Replaceable-Unit,  but  must  rely  on  circuit  boards  and  other 
electronic  components  supplied  by  private  industry.  When  aircraft  sub-systems  consisted 
primarily  of  stamped,  bent,  or  formed  metal  components,  they  could  be  repaired  at  a 
government  depot.  But  today’s  aircraft  carry  numerous  sealed  LRUs  that  are  regularly 
shipped  to  the  manufacturer  for  repair  or  replacement.  The  GAO  reported  in  1997  that, 
“Due  primarily  to  a  shortage  of  spare  parts.  Air  Force  aircraft  mission  capability  rates 
have  declined  in  recent  years  from  84.6  percent  in  fiscal  year  1990  to  74.3  percent  in 
fiscal  year  1998’’  (Government  Accountability  Office,  1997).  They  also  reported  “The 
other  major  cause  of  parts  shortages  in  September  1997  was  the  depot  maintenance 
activities’  inability  to  accomplish  timely  repair  for  53  items  reviewed.  A  major  reason  for 
this  situation  was  the  shortages  of  component  parts  to  fix  broken  repairable  items’’ 
(Government  Accountability  Office,  1997). 

The  F-15C  APG-63V1  radar  provides  an  example  of  reliance  on  private 
companies  for  LRU  replacement  and  repair.  As  briefed  in  1999,  a  partnership  between 
Raytheon  and  the  Air  Force  was  established  in  which,  “LRU’s  are  to  be  shipped  to 
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Raytheon,  repaired,  and  returned  to  Air  Foree  stoek  within  20  days  overseas,  15  days 
CONUS  from  time  of  removal  from  aireraft”  (Reid,  1999). 

The  GAO  also  reported  that  the  shortage  of  spare  parts  was  often  eaused  by 
inaccurate  forecasting  of  parts  inventory  requirements  (Government  Accountability 
Office,  1999).  As  the  military  is  involved  in  an  increasing  variety  of  conflicts  in  diverse 
locations,  it  is  likely  that  this  challenge  will  not  go  away.  The  military  will  have  to  buy 
parts  and  components  from  the  private  sector  during  periods  of  military  conflict. 

It  is  therefore  clear  military  depots  will  continue  to  rely  on  the  private  sector 
during  wartime;  the  primary  risk  Title  10  Section  2464  was  intended  to  protect  against. 
Title  lO’s  explicit  motivation  of  reducing  the  risk  of  reliance  on  the  private  sector  is  not 
realistic.  This  is  yet  another  reason  for  re-addressing  the  motive  behind  the  core 
capability  laws.  The  law  should  have  clear  motives  that  are  valid  in  today’s  environment. 
Apparent  risk  of  reliance  on  the  private  sector  should  not  be  given  priority  in  the  source 
of  repair  decision  process  while  other  factors  such  as  actual  risk  or  cost-effectiveness  are 
ignored. 

Since  the  DoD  has  successfully  relied  on  the  private  sector  during  continual 
military  conflict  since  the  Cold  War,  what  factors  other  than  private  sector  risk  should  be 
considered  in  making  source  of  repair  decisions?  DoDI  4151.20  names  one  other  factor: 
best  value  (cost-effectiveness). 


47 


Should  Cost-Effectiveness  be  Considered? 


Because  risk  was  the  primary  criterion  used  by  the  DoD  to  determine  source  of 
repair  in  the  1990’s,  cost  effectiveness  carried  little  weight  in  decision  making,  but  could 
play  a  larger  role  in  future  determinations  of  the  appropriate  source  of  repair 
(Congressional  Budget  Office,  1995).  It  is  therefore  important  to  understand  the  relevant 
attributes  of  the  public  and  private  sectors  that  affect  their  cost  effectiveness. 

The  three  relevant  attributes  of  any  depot  with  respect  to  cost  effectiveness  are 
(Congressional  Budget  Office,  1995): 

1)  Experience  maintaining  certain  systems 

2)  Size  of  facilities/state  of  the  art  repair  technologies 

3)  Size  of  workflow 

For  the  first  attribute,  the  CBO  used  the  example  of  C- 141  wing  box  repairs  for 
which  the  government  depot  was  the  least  costly  source.  An  independent  accounting  firm 
found  the  20+  years  of  experience  the  government  had  in  maintaining  the  C-141  gave  the 
government  an  inherent  advantage  over  the  private  sector.  In  fact,  the  CBO  found  a 
given  sector  tended  to  win  68  percent  of  competitions  for  work  which  had  been 
previously  accomplished  in  that  sector  (Congressional  Budget  Office,  1995). 

The  second  attribute  entails  the  infrastructure  of  depots  in  terms  of  personnel, 
facilities,  and  state  of  the  art  equipment.  The  CBO  found  this  to  be  “. .  .consistent  with 
economics  literature”  which  suggests  that  in-house  producers  of  a  good  or  service  will 
typically  use  more  highly  specialized  capital  and  production  processes  than  do  other 
suppliers,  who  try  to  reduce  risk  by  using  general  industrial  assets  and  processes  that  may  be 
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less  efficient  but  have  more  alternative  uses  (Congressional  Budget  Office,  1995).  The  DoD 
has  a  distinct  advantage  over  the  private  sector  in  this  respect.  The  DoD  generally  has  well- 
established  facilities  and  state  of  the  art  technologies  for  repair  that  may  not  exist  in  the 
private  sector  because  of  the  cost  and  risk  associated  with  these  items. 

Finally,  the  CBO  cites  the  large  and  steady  workflow  in  the  public  depots  as 
another  factor  influencing  cost  effectiveness.  They  argue  that  in  many  cases  conducting 
modifications  and  routine  maintenance  simultaneously  is  more  cost  effective 
(Congressional  Budget  Office,  1995).  Unfortunately,  combining  modifications  and 
maintenance  functions  masks  the  potential  for  another  sector  to  potentially  do 
maintenance  work  more  cost  effectively  in  the  future. 

The  CBO  cites  economic  literature  that  emphasizes  that  the  choice  between  in- 
house  and  contract  sources  is  a  choice  between  imperfect  alternatives.  They  list  the 
following  factors  that  might  make  the  private  sector  more  attractive  (Congressional 
Budget  Office,  1995): 

•  Workloads  for  which  the  DoD  could  develop  and  use  standard  contracts. 

•  Workloads  for  which  the  output  could  be  easy  to  evaluate. 

•  Workloads  for  which  competition  in  the  private  sector  was  possible. 

•  Workloads  that  private  firms  can  combine  with  new  development  or 
commercial  repairs. 
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Summary:  Is  Title  IQ’s  Oreanic  Core  Capability  Requirement  Appropriate  Today? 

In  summary,  Congress  and  the  DoD  should  begin  the  larger  discussion  about  the 
motivation  behind  the  core  capability  requirement  and  discuss  their  validity  in  today’s 
environment.  This  discussion  would  likely  meet  Congressional  resistance  because  of  one 
motive  for  keeping  this  organic  requirement:  jobs.  The  Congressional  record  over  the 
last  15  years  clearly  reveals  an  understandable  desire  on  the  part  of  its  members  to  keep 
government  depots  in  place  and  not  do  anything  that  might  decrease  their  workload  or 
threaten  jobs  back  in  the  home  district.  The  CBO  found  the  problem  to  be  as  much  about 
politics  as  it  was  about  economics: 

Large  public  depots  are  important  local  employers,  and  the  allocation  of 
work  to  the  various  depots  and  to  the  public  and  private  sectors  is  a  matter 
of  Congressional  interest.  Thus,  as  a  practical  matter,  the  decision  to  close 
or  reduce  the  size  of  a  public  depot  must  be  made  in  a  political  as  well  as 
an  economic  forum.  (Congressional  Budget  Office,  1995) 

Further  research  into  the  risk  of  reliance  on  the  private  sector  would  be  a 
necessary  foundation  for  changes  to  Title  10.  But  even  this  cursory  examination  shows 
that  the  law’s  intent  to  shield  the  government  from  private  industry  during  time  of  war  is 
not  realistic  in  today’s  environment  of  constant  conflict  and  complex  repair  relationships 
between  government  and  private  industry. 

The  discussion  now  turns  from  the  relevance  of  Title  lO’s  organic  core  capability 
requirement  to  how  the  existing  law  is  applied  today,  and  how  it  might  better  be  applied 
tomorrow  in  the  context  of  combat  aircraft  operational  flight  programs.  While  the 
relevance  of  the  law  is  worthy  of  discussion,  its  resolution  is  unlikely  to  occur  in  an 
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acceptable  timeframe.  Focusing  the  remainder  of  this  paper  on  how  to  best  operate 
within  the  eonfmes  of  the  law  offers  the  greatest  potential  for  a  reasonable  solution  in  a 
timely  manner. 
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IV.  Current  State  of  Affairs 


Introduction;  Today’s  Core  Capability  Designation  Process 

Having  accomplished  a  review  of  Title  10  and  core  logistics  policy,  the 
implementation  of  current  law  and  policy  is  now  described.  The  primary  research 
method  employed  was  the  modeling  of  policy  with  sequence  diagrams  and  functional 
models. 

Deciding  what  systems  should  be  maintained  in  support  of  an  organic  core 
maintenance  capability  is  a  process  that  is  often  misunderstood.  In  conversation,  it  is 
common  for  all  parties  involved  to  refer  to  a  particular  military  system  as  “core”  or 
“not  core”.  For  example,  the  engines  on  F-15s  are  called  “core”  because  F-15s  play  a 
role  in  our  war/contingency  scenarios  and  the  government  is  therefore  required  to  have 
the  capability  to  repair  them.  This  is  not  a  proper  interpretation. 

Properly  speaking,  a  military  system  should  not  receive  the  label  “core.”  The 
adjective  “core”  is  used  to  describe  a  maintenance  capability,  not  a  system.  Because  the 
F- 15  is  a  fighter  aircraft  that  plays  a  role  in  U.S.  war  plans  the  government  is  required  by 
Title  10  to  maintain  an  organic  capability  to  maintain  F-15  engines.  Thus,  F-15  engine 
depot-level  maintenance  is  designated  as  supporting  the  government’s  capability  to 
maintain  F-15  engines.  And  because  F-15  engines  are  similar  to  fighter  engines  in 
general,  F-15  engine  maintenance  supports  DoDs  organic  capability  to  maintain  similar 
engines  under  the  “like-workload”  principle  earlier  summarized. 
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The  subtle  differenee  between  labeling  a  system  “core”  and  labeling  a  capability 


“core”  is  evidenced  in  this  2000  US  Army  journal  article: 


It  is  difficult  to  define  "core"  and  "core  competencies"  when  discussing 
defense  operations.  For  a  commercial  business,  core  competencies  are  the 
areas  in  which  the  company  can  achieve  a  definable  preeminence  and 
provide  unique  value  for  customers.  For  Government  depots,  core  refers  to 
the  minimum  depot  size  and  composition  (personnel,  skills,  and  plant 
equipment)  required  to  support  the  most  intense  combination  of 
contingencies  specified  in  the  Defense  Planning  Guidance  . . .  Each  service 
establishes  core  programs  using  the  guidance  and  methodology  provided 
by  the  Office  of  the  Secretary  of  Defense.  Examples  of  core  programs  for 
the  Army  are  the  MlAl  Abrams  tank,  the  Bradley  fighting  vehicles,  and 
the  Patriot  missile  launcher.  So  the  Army,  by  law,  must  maintain  the 
capability  to  conduct  depot-level  repairs  on  this  equipment.  (Withers, 

2000). 

The  Title  10  requirement  for  an  organic  depot  maintenance  capability  is 
implemented  today  in  two  logically  sequential  steps: 

1 .  Identify  core  maintenance  capabilities 

2.  Calculate  the  work  capacity  required  to  maintain  these  capabilities 


Identifying  Core  Maintenance  Capabilities 

The  process  of  identifying  core  logistics  capabilities  begins  with  the  Joint  Chiefs 
of  Staff  (JCS)  wartime  scenarios.  The  JCS  not  only  develops  the  scenarios  but  also 
identifies  the  capabilities',  in  terms  of  numbers  of  specific  weapon  systems,  required  in  a 
scenario.  This  identification  of  required  military  capabilities  is  the  foundation  of  the  core 


^  The  term  "capability"  is  itself  a  potential  source  of  confusion.  In  the  context  of  JCS  scenarios,  "capability" 
refers  to  the  military  systems  required  to  achieve  particular  effects.  In  contrast,  DODI  4150.20  refers  to  a 
logistic  "capability",  defined  as  the  combination  of  skilled  personnel,  facilities  and  equipment,  processes, 
and  technology  needed  to  perform  a  particular  category  of  work,  and  that  are  necessary  to  maintain  and 
repair  the  weapon  systems  and  other  military  equipment  needed  to  fulfill  strategic  and  contingency  plans. 
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determination  process.  Any  system  identified  in  the  JCS  scenarios  by  law  must  have  an 
associated  public  sector  depot  maintenance  capability.  The  inclusion  of  a  weapon  system 
in  a  JCS  scenario  is  essentially  a  risk  analysis  and  cost  assessment  for  the  sustainment  of 
the  system.  The  output  of  this  analysis  and  assessment  is  always  the  establishment  of  a 
public  sector  depot  maintenance  capability. 

The  various  service  arms  use  the  JCS  list  of  critical  weapon  systems  to  identify 
the  sub-systems  within  those  weapon  systems  that  will  require  government  depot 
maintenance.  This  identification  of  .swh-systems  as  requiring  maintenance  that  satisfies 
organic  core  maintenance  capability  is  currently  a  subjective  process  that  is  applied 
differently  across  services  (AFMC/A4DC,  2009). 

The  method  employed  by  the  Air  Force  is  to  identify  the  capabilities  required  for 
a  given  weapon  system  to  meet  the  JCS  scenario  and  then  aggregate  up  to  the  most 
logical  system  grouping.  An  example  would  be  the  requirement  of  a  given  weapon 
system  to  employ  secure  voice  communications.  Via  aggregation,  the  entire 
communication  system  therefore  requires  a  core  logistics  capability.  By  contrast,  the 
Navy  currently  makes  core  determinations  on  a  part-by-part  basis  (AFMC/A4DC,  2009). 

DODI  4151.20  provides  a  flow  chart  for  determining  which  systems  require  core 
logistics  support  and  another  for  calculating  direct  labor  hours  (DLHs).  Before  examining 
this  source  of  repair  decision  process  in  detail,  Figure  13  provides  a  brief  summary.  The 
process  begins  with  one  question  and  then  three  differing  categories  of  law  and  policy  are 
applied. 
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Source  of  Repair  Determination  -  In  Brief 


Is  the  system  in 


a  JCS  sc 

\ 

enario? 

YES 

/ 

NO 

Apply ''core'' 
law  and  policy 

N 

Apply  "50/50" 
law  and  policy 

N 

/ 

Apply  "Best  Value" 
law  and  policy 

Figure  13.  Source  of  repair  decision  -  in  brief 
(DoDI  4151.20  Depot  Maintenance  Core  Capabilities  Determination  Process,  2007) 

Calculating  the  Work  Capacity  Required  to  Maintain  Core  Capabilities 

Identifying  what  is  a  core  capability  is  not  sufficient,  however,  to  ensure  the 
capability  exists.  Like  any  system,  the  depot  must  maintain  its  ability  to  perform 
workload  on  mission  essential  systems.  The  capability  to  perform  certain  depot  work 
must  therefore  be  quantified.  The  DoD  quantifies  its  core  capability  in  terms  of  Direct 
Labor  Hours  (DLH).  A  minimum  amount  of  work  must  occur  in  the  public  depot  during 
peacetime  to  maintain  the  capability  to  perform  required  maintenance  actions  during  time 
of  war.  The  DLHs  also  aid  in  determining  the  size  and  number  of  facilities  and  the  type 
and  number  of  personnel. 

DODI  4150.20  provides  two  detailed  charts  for  use  in  calculating  the  required 
DLHs  for  a  particular  system  and  ultimately  its  source  of  repair.  The  content  of  these 


55 


two  charts  is  combined  in  Figure  14,  omitting  minor  processes  such  as  the  exclusion  of 
systems  excepted  from  the  core  process  by  the  Secretary  of  Defense. 


Source  of  Repair  Determination 
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NO 


Work  given  to 
publicdepot 
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Private  Depot 


Work  given  to 
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Figure  14.  Source  of  repair  determination  (DODI  4151.20,  2007) 
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Block  A.  The  top  of  the  flow  chart  begins  with  a  new  system — the  F-35  engine 
for  example.  After  Initial  Operational  Capability  (IOC)  is  declared,  the  F-35  will  be  a  key 
player  in  JCS  war  plans  and  contingency  scenarios  and  the  government  is  therefore 
required  to  maintain  the  capability  to  maintain  its  various  subsystems.  The  F-35  program 
office  estimates  that  508,000  labor  hours  will  be  required  in  peacetime  to  perform  depot 
level  maintenance  on  the  F-35  engine  (Block  B).  If  the  system  in  question  does  not  play 
a  role  in  JCS  contingency  scenarios,  much  of  the  decision  tree  is  skipped,  and  only  the 
“50/50”  law  is  applied  (discussed  later). 

Block  C.  Next,  the  labor  hours  are  reduced  by  the  proportion  of  F-35s  that  will 
be  used  in  the  scenarios.  Because  some  of  the  jets  are  used  for  training  and  others  are 
unavailable  for  other  reasons,  it  is  estimated  that  70  percent  of  the  F-35  fleet  will  be 
tasked  in  JCS  scenarios.  Seventy  percent  of  508,000  hours  is  355,000  hours. 

Block  D.  Because  work  on  a  specific  subsystem  will  typically  increase  in 
preparation  for  a  contingency  or  war,  the  peacetime  hours  are  adjusted  for  maintenance 
surge  at  the  beginning  of  an  operation/contingency.  Using  historical  data  from  other 
aircraft,  the  F-35  program  office  predicts  that  engine  maintenance  workload  will  increase 
by  a  factor  of  1.5  during  war.  The  355,000  hours  of  maintenance  now  becomes  532,000 
war  time  labor  hours. 

Block  E.  Next,  the  war  time  labor  hours  are  adjusted  for  the  ability  of  the 
government  depot  to  work  overtime  during  the  wartime  surge.  The  common  “resource 
adjustmenf’  multiplier  in  use  today  is  1.6.  The  532,000  labor  hours  needed  in  war  are 
divided  by  1.6,  resulting  in  333,000  hours.  In  summary,  the  government  depot  must 
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perform  333,000  labor  hours  on  F-35  engine  maintenance  during  peace  time  in  order  to 
maintain  the  capability  to  perform  all  depot  maintenance  on  70  percent  of  all  F-35 
engines  in  time  of  war. 

But  this  is  not  the  end  of  the  flowchart.  The  government  depot  may  already 
expend  many  labor  hours  maintaining  similar  engines,  or  the  work  may  be  tasked  out  to 
the  depot  of  a  sister  service.  The  lower  half  of  the  chart  is  used  to  consider  several  ways 
the  core  workload  hours  may  be  further  adjusted. 

Block  F.  Before  the  F-35  engine  is  considered,  the  government  depot  has  been 
maintaining  engines  from  other  fighter  aircraft.  Workload  data  from  this  existing  work 
now  enters  the  picture.  If  the  government  depot  does  not  have  enough  work  to  maintain 
the  capability  to  repair  fighter  engines,  some  or  all  of  the  F-35  engine  maintenance  labor 
hours  will  be  given  to  the  government  depot  in  support  of  the  capability  to  repair  fighter 
engines.  If  any  labor  hours  remain  after  this  step,  the  hours  continue  down  the  tree. 

Block  G.  The  Secretary  of  Defense  may  direct  that  maintenance  on  a  system  be 
performed  by  the  government,  in  which  case  the  remaining  labor  hours  are  allocated  to 
the  public  depot. 

Block  H.  Next,  remaining  hours  are  given  to  the  public  sector  if  no  suitable  depot 
maintenance  capability  exists  in  the  private  sector.  If  private  depot  maintenance 
capability  exists,  the  remaining  hours  continue  to  the  next  block. 

Block  I.  Title  10  Section  2464  requires  the  Secretary  of  Defense  to  allocate 
enough  work  to  the  government  depots  to  maintain  their  “cost  efficiency”  and  “technical 
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competence.”  If  the  government  depot  is  laeking  in  either  area,  labor  hours  are  sent  to 
publie  depots  at  this  step. 

Block  J.  If  any  labor  hours  remain  at  this  point  in  the  process,  Section  2466  of 
Title  10  is  applied.  This  law  requires  that  a  minimum  of  50  percent  of  all  funds  spent  for 
depot  level  maintenanee  of  military  systems  be  spent  in  the  public  sector.  Continuing  the 
F-35  example,  if  the  Air  Foree  is  eurrently  below  the  50  percent  floor  aeross  the  board, 
F-35  engine  labor  hours  would  be  alloeated  to  the  government  depot. 

Block  K.  Lastly,  any  remaining  hours  are  competed  between  the  publie  and 
private  sectors  for  best  value  (cost-effectiveness). 

After  direet  labor  hours  are  alloeated  to  a  government  depot,  these  hours  are 
converted  into  dollar  amounts  that  are  used  by  the  Planning,  Programming,  and 
Budgeting  System  (PPBS)  to  determine  appropriate  funding  for  the  identified 
capabilities. 

Note  the  dominant  factor  that  drives  depot  labor  hours  to  the  publie  sector  is  Title 
lO’s  motive  of  avoiding  the  risk  of  private  seetor  work.  Cost-effectiveness  is  not  a 
primary  eoneem  until  the  end  of  the  deeision  tree. 

Functional  Model  of  the  Source  of  Repair  Decision  Process 

While  the  flow  ehart  above  provides  a  good  overview  of  the  decisions  involved  in 
the  eore  capability  determination  proeess,  it  does  not  reveal  several  key  factors  that  affect 
these  deeisions.  This  researeh  team  developed  a  functional  model  of  the  source  of  repair 
(SCRAP)  decision  process  whieh  is  now  presented  in  the  eommon  IDEFO  (Integration 
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Definition  Functional  Model)  format  (Figure  15).  Each  block  represents  a  function  or 
activity.  Inputs  arrive  from  the  left  side  of  a  block,  outputs  leave  from  the  right, 
mechanisms  are  depicted  along  the  bottom,  and  controls  that  guide  the  function  or 
triggers  that  begin  the  activity  are  shown  along  the  top  of  a  block.  The  advantage  of  the 
IDEFO  model,  in  this  case,  is  that  it  depicts  the  mechanisms  for  making  decisions  or 
accomplishing  tasks.  This  is  in  contrast  to  the  decision  tree  model  which  simply  shows 
the  flow  of  information  and  required  decisions.  Several  additional  observations  can  now 
be  made  about  the  source  of  repair  decision  process. 
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Figure  15.  SORAP  Functional  Model  (as-is) 
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First,  application  of  law  and  policy  can  generally  be  placed  into  three  categories 
depicted  by  blocks  A.3,  A.4,  and  A.5  in  Figure  15.  Each  of  these  categories  divides  labor 


hours  or  labor  funds  between  the  public  and  private  sectors  by  different  rules  and  for 


different  motives. 

Rule 

1 .  Core  capability  laws 

2.  50/50  laws 

3 .  Best  value  /  cost-effectiveness 


Motive 

Protection  from  risk  of  private  sustainment 

Several  motivations  in  tension 

Value  (  for  work  not  covered  by  #1  and  #2) 


We  now  follow  the  process  model  and  describe  each  function  along  the  way.  A 
variety  of  triggers  can  start  the  process.  The  most  common  trigger  is  the  start  of  a  new 
program/system  that  will  require  sustainment.  Other  triggers  include  a  change  in  the 
war/contingency  scenarios  published  by  the  Joint  Chiefs  of  Staff  or  workloads  at  public 
depots  falling  below  the  minimum  required  to  support  a  core  maintenance  capability. 

Calculations  required  to  determine  if  an  organic  capability  shortfall  exists  are 
regularly  accomplished  and  are  represented  in  the  model  by  function  A.2.  The  primary 
mechanisms  for  function  A.2  are  the  government  depots,  which  generate  labor  reports 
that  are  used  in  identifying  any  capability  shortfalls.  The  controls  on  this  process  are  the 
laws  and  policies  earlier  summarized,  which  specify  the  frequency  of  reporting,  the 
parties  involved,  and  the  content  of  the  information  reported.  Title  10  provides  the 
foundational  requirement  for  reporting,  and  DOD  and  service-level  instructions  provide 
amplifying  detail. 
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If  the  starting  trigger  is  a  new  system  sueh  as  the  F-35  airframe,  the  first  decision 
point  is  a  simple  determination  of  the  system’s  role  in  JCS  contingency  scenarios. 
Because  the  F-35  airframe  does  play  a  role  in  war  plans,  core  policy  is  next  applied 
(function  A.3).  Systems  that  are  not  included  in  war  taskings,  such  as  training  systems, 
bypass  the  core  laws  and  enter  at  function  A.4  where  50/50  laws  are  applied. 

The  core  policy  function  analyzes  the  system  characteristics  (F-35  airframe  for 
example)  and  determines  what  portion  of  maintenance  workload  is  required  by  Title  10 
section  2464  to  be  performed  by  a  government  depot.  Representatives  from  several 
organizations  serve  as  mechanisms  for  this  process.  Mechanism  organizations  include 
USAF  program  offices  and  AFMC  headquarters.  At  this  point,  a  series  of  DoD  and  Air 
Force  instructions  guide  the  process  by  controlling  how  calculations  are  performed  and 
when  exceptions  are  authorized,  based  on  Title  10. 

Function  A.4  then  applies  50/50  laws  and  policies  which  require  that  a  minimum 
of  50  percent  of  all  depot  maintenance  funding  be  spent  on  organic  work.  Any  labor 
hours  not  allocated  to  the  government  by  this  function  are  passed  to  block  A.  5. 

The  CBO  and  other  interested  parties  have  often  argued  for  a  greater  role  for  the 
Best  Value  function  (function  A.5).  The  SORAP  functional  model  reveals  that  core  and 
50/50  laws  are  the  top  priority.  Cost-effectiveness  does  not  become  the  primary  workload 
allocation  filter  until  well  down  the  tree.  Any  workload  that  reaches  this  level  in  the 
process  is  competed  between  private  and  public  sectors.  Again,  increasingly  detailed 
policy  controls  this  process. 
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In  the  end,  all  depot-level  maintenance  workload  is  allocated  to  either  the  public 
or  private  sectors.  This  workload  can  be  split  between  the  two  sectors  for  a  single  system 
or  subsystem — not  all  labor  must  be  given  to  one  or  the  other.  Functions  A.6  and  A.7 
represent  the  actual  depot-level  maintenance  work  of  the  public  and  private  sectors 
respectively.  The  mechanisms  for  this  work  include  the  buildings,  equipment,  people, 
and  money  available  to  each  depot. 

Up  to  this  point,  funding  source  (“color  of  money”)  has  had  no  influence  on  the 
process.  Functions  A.6  and  A.7  require  the  proper  source  of  funding  for  budgeting 
purposes.  As  a  rule,  the  only  appropriations  intended  for  the  performance  of  maintenance 
are  funds  coded  3400  in  the  DoD  Financial  Management  Regulation  (DODI  7000. 14-R). 
This  category  of  funding  is  to  be  used  for  systems  operations  and  maintenance,  regardless 
of  whether  the  work  is  done  organically  or  by  private  contractor  (DoD  7000. 14-R 
Volume  2A  Financial  Managment  Regulation,  2008). 

Functional  Model  Application;  Aircraft  OFPs 

Today,  modification  to  a  fielded  OFF  is  normally  treated  as  maintenance  by 
AFMC  and  is  therefore  governed  by  the  requirements  of  core  capability  laws.  Given  that 
OFF  modification  is  classified  as  maintenance,  when  OFF  workload  for  a  given  aircraft 
arrives  at  the  last  two  blocks  in  the  functional  model  the  only  funding  mechanism 
appropriate  is  3400  money  (O&M  funds).  However,  interviews  with  government  depots 
and  program  offices  revealed  that  sufficient  3400  coded  funding  is  often  not  available  for 
the  workload  required  to  update  an  OFF.  Funding  coded  for  R&D  (3600)  is  sometimes 
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used  instead  (WR-ALC  Interview,  2010).  In  the  ideal  situation,  work  associated  with 
OFF  modification  would  be  designated  either  maintenance  or  development,  and  the  type 
of  funds  appropriate  to  this  work  would  be  budgeted,  and  spent. 

As  this  research  will  argue  in  following  chapters,  much  OFF  work  is  development 
and  not  maintenance,  so  it  is  logical  to  use  3600  money.  But  the  functional  model  of  the 
process  reveals  that  if  OFF  work  is  considered  maintenance,  the  only  funding  mechanism 
authorized  is  3400  money.  This  reveals  the  problem  created  by  categorizing  OFF  work 
as  maintenance:  maintenance  laws  are  applied  up  front  for  depot  workload  allocation, 
while  the  funding  process  effectively  recognizes  the  work  as  development. 

Functional  Model  Application:  T-38  Engine  (training  system) 

Because  training  systems  are  not  part  of  JCS  contingency  plans,  such  systems 
initially  bypass  core  policy  and  enter  at  function  A.4  (50/50  laws).  However,  because 
organic  core  capability  is  periodically  assessed  (function  A.2),  it  could  be  that  at  some 
point  the  government  lacks  the  capability  to  perform  work  on  fighter-type  engines  due  a 
workload  shortfall  in  this  area,  triggering  a  re-evaluation  of  existing  systems.  If  the  T-38 
engine  was  similar  to  combat  coded  fighter  engines  (in  reality  it  is  not),  maintenance 
workload  on  the  T-38  engine  might  be  allocated  to  the  government  to  help  restore  an 
organic  capability  in  this  area. 

Functional  Model:  Hardware  and  Software  Contrasted 

If  engine  workload  is  given  to  the  government,  the  remaining  work  is  easily 
allocated  to  the  private  sector.  For  example,  the  government  depot  would  be  given  100 
T-38  engines  to  sustain  and  the  private  depot  would  also  be  given  100  engines.  But  when 
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it  comes  to  OFP  modification,  splitting  workload  is  much  more  difficult.  Unlike 
hardware  which  exists  in  many  duplicate  copies,  a  single  OFP  is  loaded  into  all  aircraft  of 
a  type.  An  OFP  cannot  be  split  like  a  group  of  engines.  Portions  of  an  OFP  could  be 
modified  by  different  organizations,  but  the  various  portions  of  an  OFP  are  highly 
coupled.  In  contrast,  the  work  done  on  one  aircraft  engine  does  not  affect  the  work  done 
on  another  engine  of  the  same  type. 

In  this  context,  both  the  sequence  model  (Figure  14)  and  the  functional  model 
(Figure  15)  portray  a  system  that  is  well-suited  to  the  allocation  of  maintenance  workload 
for  hardware,  but  not  well-suited  for  software.  While  the  challenge  of  dividing  and 
allocating  software  modification  workload  persists,  the  current  process  can  be  modified 
to  allow  greater  flexibility. 

These  improvements,  along  with  further  analysis  of  the  differences  between 
hardware  and  software,  are  examined  in  the  following  chapters. 

Current  State  of  Affairs:  Summary 

The  strain  between  the  DoD’s  desire  to  perform  cost  effective  depot  maintenance 
and  Congress’s  aversion  to  the  alleged  risks  associated  with  excessive  privatization  of 
depot  maintenance  appears  to  have  found  a  neutral  point  in  the  Title  10  core  capability 
requirement  and  the  50/50  rule,  allowing  DoD  some  flexibility  while  retaining  necessary 
capabilities  in  public  sector.  As  recently  as  2008,  the  GAO  report  Issues  and  Options  for 
Reporting  on  Military  Depots  provided  Congress  with  the  following  key  issues  to 
consider  (Government  Accountability  Office,  2008). 
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•  To  what  extent  are  50/50  and  core  still  relevant  for  assessing  a  required 
level  of  organic  maintenance  capability? 

•  What  role  are  the  depots  to  have  in  DoD  weapons  system  support?  Are 
they  to  be  only  used  for  legacy  systems  and  as  repairers  of  last  resort  when 
a  contractor  is  not  available,  or  are  they  to  be  a  key  source  of  repair  for 
new  and  modified  weapon  systems? 

•  How  does  core  depot  maintenance  fit  into  a  DoD  support  scenario  in  light 
of  DoD’ s  preference  for  using  performance-based  logistics? 

•  If  the  maintenance  depots  are  to  remain  relevant  in  the  future,  what  actions 
are  needed  to  ensure  they  are  modernized  and  capable  of  performing 
maintenance  on  new  systems? 

•  As  it  becomes  more  difficult  to  distinguish  depot  from  intermediate 
maintenance  and  maintenance  from  other  supportability  functions,  to  what 
extent  does  it  remain  practicable  to  quantify  a  balance  of  public  and 
private  sector  depot  maintenance? 

•  Is  it  important  for  DoD  to  continue  to  define  some  level  of  core  capability 
that  it  should  perform  using  DoD  military  or  civilian  employees? 


These  questions  are  similar  to  questions  independently  generated  by  this  research 
team  and  validated  perceptions  regarding  the  debate.  The  answers  to  these  questions, 
which  will  undoubtedly  shape  the  way  the  DoD  performs  depot  maintenance  in  the 
future,  are  outside  the  scope  of  this  research.  This  research  is  focused  primarily  on 
identifying  ways  to  more  effectively  operate  within  constraints  of  current  law. 
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V.  What  is  Software  Maintenance?  Toward  a  Common  Dictionary 


Software  Sustainment  Definitions  Compared  and  Contrasted 

Review  of  existing  policy,  government  reports,  and  trade  journals  revealed 
inconsistent  and  confusing  use  of  key  terms  related  to  software  sustainment.  Lack  of  a 
common  lexicon  may  be  one  reason  for  confusion  and  frustration  with  the  core 
designation  process. 

Beyond  the  annoyance  of  confusing  terms  is  the  massive  cost  associated  with  this 
phase  of  the  software  lifecycle.  Estimates  report  that  sustainment  accounts  for  60-90 
percent  of  the  total  lifecycle  cost  of  a  software  product  (Department  of  the  Air  Force 
Software  Technology  Support  Center,  2003).  Misinterpreting  a  definition  could  therefore 
cause  expensive  investment  in  an  organic  maintenance  capability  when  in  fact  the  work  is 
mostly  development.  In  this  context,  a  set  of  common  definitions  is  essential. 

Therefore,  this  research  team  surveyed  existing  law,  policy,  regulations, 
guidebooks,  and  trade  journals  for  definitions  of  the  following  terms: 

•  Sustainment 

•  Maintenance 

•  Development 

Varying  definitions  for  each  term  were  then  compared  and  contrasted,  analyzing 
which  documents  contained  definitions  similar  to  other  documents,  and  where  definitions 
were  missing.  Following  this  analysis,  a  common  lexicon  of  terms  related  to  the 
development  and  maintenance  of  both  hardware  and  software  was  developed  for 
integration  into  policy  documents.  This  improvement  to  policy  documents  would  allow 
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more  consistent  use  and  understanding  of  terms  and  in  turn  more  make  more  effective  use 
of  limited  funding. 

Analysis  of  the  lexicon  associated  with  depot  level  sustainment  of  hardware  and 
software  systems  begins  with  identification  of  the  key  terms.  Next,  the  team  summarizes 
which  sources  agree  and  which  sources  differ  in  their  definitions  of  these  terms.  Lastly, 
policy  documents  and  Air  Force  instructions  are  identified  which  omit  definitions  where 
they  would  otherwise  be  useful  in  implementing  depot  maintenance  policy. 

Summary  of  Existing  Definitions 

A  common  lexicon  is  critical  to  understanding,  communicating,  and 
implementing  the  depot  maintenance  requirements  of  Title  10  and  associated  DoD  policy. 
Table  2  provides  a  quick  summary  of  which  documents  address  each  of  the  key  terms 
related  to  materiel  and  software  sustainment,  maintenance  and  development.  The  full 
complement  of  definitions  can  be  found  in  Appendix  A:  Definitions.  Of  note,  the  term 
“development”  was  never  adequately  defined  in  any  of  the  documents  surveyed  and  is 
therefore  not  reflected  in  Table  2.  In  its  place,  however,  policy  documents  do  include 
related  terms.  The  column  labeled  “Related  Terms”  contains  all  definitions  that  do  not  fit 
in  the  categories  of  sustainment  and  maintenance.  In  many  cases,  these  definitions  refer 
to  development,  modernization,  or  evolution  of  systems. 
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Table  2.  Mapping  of  publications  to  related  definitions 
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As  outlined  previously,  the  next  step  was  to  map  agreeing  definitions  between 
sources.  While  no  instances  of  definitions  blatantly  disagreed  between  documents,  a 
common  lexicon  could  still  help  clarify  policy  decisions  regarding  software  sustainment. 
Table  3  maps  definitions  between  policy  documents  and  reveals  which  definitions  are 
common  among  multiple  documents.  Definitions  are  grouped  by  level  in  the  policy 
hierarchy  (i.e.  DoD  level  versus  Air  Force  level).  Such  groups  are  represented  by  a  light 
grey  box  around  the  definitions. 

This  table,  a  fit-for-purpose  architecture  product,  is  loosely  based  on  the  DoD 
Architecture  Framework  (DODAF)  SV-3  Systems-Systems  Matrix  (DoD  Architecuture 
Framework  Version  2.0,  2009).  In  an  SV-3,  relationships  among  systems  are  mapped 
and  highlighted.  Table  3  substitutes  systems  for  policy  documents  but  depicts 
relationships  similarly  to  an  SV-3. 
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Table  3.  Definition  mapping  (depicts  groupings  of  common  definitions) 


Title  10  1 

DoD  5000.01  1 

DoD  5000.02  1 
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00 
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< 

AFI  63-101  1 
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AFI  65-601  1 
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M 
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M 
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M 
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M 
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M 
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SM 

S 
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S 
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M 

M 
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M 
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This  graphical  representation  of  the  eurrent  fragmented  lexicon  permits  an 
important  observation.  The  elumping  of  definitions  at  a  given  level  (i.e.  DoD-level 
poliey)  indicates  a  lack  of  lexicon  continuity  between  hierarehal  levels.  For  instance, 
there  are  no  common  definitions  between  Title  10  and  the  USAF  Weapon  System 
Software  Manual.  Likewise,  there  is  a  high  degree  of  commonality  among  DoD  policy 
documents  but  very  little  between  DoD  doeuments  and  Air  Force  documents.  This  laek 
of  a  eommon  lexicon  may  explain  mueh  of  the  current  frustration  with  the 
implementation  of  core  logistics  laws. 

Additional  patterns  emerged  after  definitions  were  binned  and  eompared.  The 
first  was  a  lack  of  consistency  in  defining  “sustainment”.  Very  few  doeuments  formally 
defined  sustainment  and  those  that  did  had  varied  definitions.  Those  that  did  not  define 
sustainment  tended  to  identify  aetivities  that  fall  under  the  umbrella  of  sustainment  rather 
than  deseribe  the  sustainment  effort  itself.  Secondly,  definitions  of  “sustainment”  are 
absent  altogether  at  the  bottom  of  the  doeument  hierarehy.  The  one  exeeption  to  this  is 
the  Guidelines  for  Suceessful  Acquisition  and  Management  of  Software  Intensive 
Systems  (GSAM)  Handbook.  The  speeifics  of  this  handbook  will  be  discussed  later. 

The  next  trend  was  the  lack  of  an  attempt  to  define  software  maintenanee  in  the 
higher  level  documents.  The  first  attempt  to  define  software  maintenanee  does  not  oceur 
until  AFI  63-101  Acquisition  and  Sustainment  Life  Cycle  Management.  At  first  glanee 
this  may  seem  logical,  as  the  law  and  DoD  documents  are  eoncemed  with  broad  aspects 
of  policy.  But  the  detail  with  whieh  they  deseribe  hardware  maintenance  proves 
otherwise.  These  documents  use  the  term  “software  maintenance”  yet  fail  to  provide  a 
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definition.  For  example,  DoD  4151. 18-H  Depot  Maintenance  Capacity  and  Utilization 
Measurement  Handbook  Aescvihes  “maintenance”  as: 

The  processes  of  materiel  maintenance  or  repair  involving  the  overhaul, 
upgrading,  rebuilding,  testing,  inspection,  and  reclamation  (as  necessary) 
of  weapons  systems,  equipment  end  items,  parts,  components,  assemblies, 
and  subassemblies.  (DoD  41 51. 18-H  Depot  Maintenance  Capacity  and 
Utilization  Measurement  Handbook,  2007) 

Compare  that  detailed  definition  to  this  simple  reference  to  software  maintenance: 
“Depot  maintenance  also  includes  all  aspects  of  software...”  (DoD  41 51. 18-H  Depot 
Maintenance  Capacity  and  Utilization  Measurement  Handbook,  2007).  The  comparison 
indicates  the  DoD  does  not  view  software  maintenance  to  be  any  different  than  hardware 
maintenance  and  therefore  requires  no  further  explanation. 

Ambiguity  in  the  use  of  terms  is  common  at  the  lower  end  of  the  document 
hierarchy  as  well.  The  Guidelines  for  Successful  Acquisition  and  Management  of 
Software  Intensive  Systems  (GSAM),  NA  VAIR  Software  Logistics  Primer,  and  the  USAF 
Weapon  Systems  Software  Management  Guidebook,  rarely  use  the  term  “maintenance”  in 
the  context  of  software.  The  GSAM  uses  the  term  “software  sustainmenf’  instead  of 
“software  maintenance”,  yet  its  description  of  activities  which  constitute  software 
sustainment  are  identical  to  those  activities  called  software  maintenance  in  other 
documents.  Likewise,  the  NAVAIR  primer  refers  to  “software  maintenance”  but  follows 
with  a  parenthetical  “a.k.a.  software  sustainment”  (Naval  Air  Systems  Command,  2008). 

Lastly,  the  USAF  Weapons  System  Software  Management  Guidebook  refers  to 
“software  repair''  and  then  states  that  the  processes  required  to  repair  software  are  very 
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similar  to  those  used  to  develop  it  (Office  of  the  Secretary  of  the  Air  Force  for 
Acquisition,  2008).  Taken  as  a  whole,  these  three  documents  link  software  maintenance 
to  software  repair,  software  sustainment,  and  software  development.  However,  they  add 
confusion  to  the  software  repair  versus  sustainment  discourse  because  they  fail  to  define 
a  common  definition. 

As  previously  stated,  the  DoD  does  not  recognize  a  difference  between  software 
and  hardware  maintenance  as  evidenced  in  DoD  4150.18-H.  Therefore,  before  a 
common  dictionary  is  proposed,  hardware  and  software  maintenance  is  compared  and 
contrasted  in  greater  detail  to  demonstrate  the  differences. 

Hardware  and  Software  Maintenance  Contrasted 

When  the  question  arises,  “What  makes  software  different?”,  the  answer  is  varied 
and  complex.  The  first  answer  is  that  software  is  invisible  and  intangible  (Naval  Air 
Systems  Command,  2008).  Software  does  not  exist  in  the  same  manner  as  a  piece  of 
hardware.  One  can  describe  a  piece  of  hardware  through  a  set  of  drawings  and 
specifications.  Because  software  is  essentially  information-only  (logical  decision  rules),  it 
must  be  described  by  what  it  does  rather  than  what  it  is.  One  cannot  draw  a  picture  of  a 
piece  of  software.  Instead,  one  describes  the  structure  of  the  software  logic  (Crane, 

2009).  The  processes  for  designing  and  maintaining  software  are  therefore  fundamentally 
different  from  those  of  hardware. 

Second,  software  is  designed  but  not  manufactured  (Crane,  2009).  The  outcome 
of  the  hardware  design  process  is  a  set  of  blueprints  or  plans  which  are  used  to 
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manufacture  products  (often  in  great  quantity)  which  are  typically  operated  separately 
from  each  other.  For  example,  two  engines  of  the  same  design  are  in  use  in  different 
squadrons.  In  contrast,  the  output  of  software  design  is  a  single  software  product  that  is 
operated  by  many  users  independently.  Two  identical  engines  are  made  of  different 
chunks  of  matter.  But  two  installations  of  the  same  OFF  are  made  of  the  same 
information.  Software  is  therefore  designed,  produced,  and  operated,  but  not 
manufactured.  Figure  16  is  a  graphical  depiction  of  this  contrast. 


Figure  16.  Software  and  hardware  differences  (Hemmes,  2009) 


Another  important  difference  between  software  and  hardware  is  that  software 
does  not  break  or  wear  out  (Crane,  2009).  A  piece  of  hardware  wears  out  over  time  and 
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may  break  or  fail  during  its  lifecycle.  When  this  occurs,  one  simply  repairs  the  worn  out 
part  or  replaces  it  with  a  spare  part  (Crane,  2009).  This  is  not  the  case  with  software. 
Software  does  not  break  and  could  theoretically  be  operated  indefinitely  without  wearing 
out.  There  are  no  spare  parts  for  software  (Crane,  2009).  Software  does,  however, 
deteriorate  with  respect  to  its  environment.  The  deterioration  of  software  is  primarily 
caused  by  a  changing  operating  environment  or  due  to  unexpected  combinations  of 
inputs.  Software  deterioration  is  directly  traceable  to  flaws  in  design  (Crane,  2009). 

Software  deterioration  is  a  common  occurrence  for  many  people.  Something  as 
innocuous  as  installing  a  new  program  can  cause  part  or  all  of  the  system  to  function 
abnormally.  Figure  17  graphically  represent  the  differences  between  software  and 
hardware  failure  rates  as  a  function  of  time.  The  right  plot  specifically  shows  that 
software  failures  approach  a  near  constant  rate.  In  contrast,  hardware  (left  plot)  exhibits  a 
constant  failure  rate  for  a  period  of  time,  but  then  begins  to  fail  at  an  exponentially 
increasing  rate. 
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Figure  17.  Software  and  hardware  failure  rates  over  time  (Crane,  2009) 
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Finally,  software  is  not  maintained  in  the  classical  sense  of  maintenance  (Crane, 
2009).  Hardware  maintenance  consists  of  preventative  maintenance  (replacing 
consumables  such  as  oil  or  replacing  parts  prior  to  failure)  and  corrective  maintenance 
(repairing  or  replacing  failed  parts).  Additionally,  hardware  maintenance  simply  returns 
the  system  to  its  designed  functionality;  it  does  not  add  new  functionality  or  capability. 
This  is  not  the  case  for  software.  “Software  maintenance”  as  used  in  industry  is  much 
more  broad,  and  the  line  between  software  maintenance  and  development  is  blurry  at 
best.  In  fact,  “it  is  reported  that  very  few  organizations  adopt  a  separate  process  for 
[software]  maintenance  because  they  cannot  make  a  distinction  between  software 
maintenance  and  development”  (Sharma,  2004). 

ISO/IEC  12207  Software  Lifecycle  Processes  offers  a  guide  to  the  various 
software  lifecycle  events.  Figure  18  shows  the  processes  involved  within  the  lifecycle  of 
a  given  piece  of  software.  This  document  also  recognizes  an  inherent  link  between 
software  development  and  maintenance  actions  as  development  is  a  dependent  process  to 
maintenance.  In  his  synopsis  of  ISO/IEC  12207,  Raghu  Singh  of  the  Federal  Aviation 
Administration  states  “Whenever  a  software  product  needs  modifications,  the 
development  process  is  invoked  to  effect  and  complete  the  modification  properly” 
(Singh,  1998). 
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Figure  18.  Software  lifecycle  process  diagram  (Singh,  1998) 

The  difference  between  software  maintenance  and  hardware  maintenance  can  also 

be  understood  intuitively.  For  example,  suppose  we  were  to  accomplish  aircraft  landing 
gear  maintenance  by  invoking  hardware  development,  as  is  practiced  in  software 
maintenance.  An  aircraft  lands  hard  and  one  of  the  gear  struts  is  damaged.  If  the 
software  maintenance  paradigm  were  applied,  the  repair  of  the  landing  gear  strut  would 
involve  the  design  of  a  new  part.  Now  the  example  is  reversed.  After  a  period  of  time  the 
same  aircraft  requires  maintenance  on  its  OFF.  If  software  maintenance  was  performed 
with  the  hardware  paradigm,  maintenance  personnel  would  simply  install  into  the  aircraft 
a  fresh  copy  of  the  same  OFF.  Both  of  these  scenarios  seem  absurd,  but  are  useful  in 
illustrating  the  fact  that  hardware  maintenance  and  software  maintenance  are 
fundamentally  different  undertakings. 


Eight  Laws  of  Software  Evolution 

The  differences  between  software  and  hardware  maintenance  can  be  summed  up 
in  one  term  -  Evolution.  The  maintenance  of  hardware  is  a  static  undertaking.  A  piece  of 
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hardware  should  function  the  same  before  and  after  a  maintenance  action.  In  fact,  the  one 
thing  most  of  the  surveyed  policy  documents  agreed  upon  was  that  maintenance  primarily 
serves  to  return  or  retain  an  end  item  to  serviceability  (DoDI  4151.20  Depot  Maintenance 
Core  Capabilities  Determination  Process,  2007). 

Software,  on  the  other  hand,  will  structurally  look  and  possibly  function 
differently  before  and  after  a  maintenance  action.  The  idea  that  software  exhibits  an 
evolutionary  nature  is  not  new.  As  early  as  the  1970s,  studies  were  conducted  on  software 
systems  to  characterize  their  nature.  As  a  result  of  these  and  subsequent  studies,  eight 
laws  that  govern  the  evolutionary  nature  of  software  have  been  defined.  The  eight  laws  of 
software  evolution  are  (Lehman,  1997): 

1 .  Continuing  Change  -  A  program  that  is  used  must  be  continually  adapted  or  else 
it  becomes  progressively  less  satisfactory. 

2.  Increasing  Complexity  -  As  a  program  evolves  it  becomes  increasingly  more 
complex  unless  work  is  done  to  reduce  it. 

3.  Self  Regulation  -  The  evolution  process  is  self  regulating  with  close  to  normal 
distribution  of  measures  of  products  and  process  attributes. 

4.  Conservation  of  Organizational  Stability  -  The  average  effective  global  activity 
rate  on  an  evolving  system  is  invariant  over  the  product  life  time. 

5.  Conservation  of  Familiarity  -  During  the  active  life  of  an  evolving  program,  the 
content  of  successive  releases  is  statistically  invariant. 

6.  Continuing  Growth  -  Functional  content  of  a  program  must  be  continually 
increased  to  maintain  user  satisfaction  over  its  lifetime. 

7.  Declining  Quality  -  Programs  will  be  perceived  as  of  declining  quality  unless 
rigorously  maintained  and  adapted  to  a  changing  operational  environment. 
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8.  Feedback  System  -  Must  be  treated  as  multi-loop,  multi-level  feedback  systems  to 

be  successfully  modified  or  improved. 

Laws  1,  2,  6,  and  7  will  be  discussed  because  they  are  most  relevant  to  the  issue 
of  classifying  an  OFF  modification  as  either  maintenance  or  development.  The  other  four 
laws  are  no  less  important  to  understanding  the  nature  of  software  evolution  but  are  not 
germane  to  this  discussion  because  they  deal  with  the  impact  of  software  evolution  on 
software  modification  processes  and  not  with  the  software  itself 

The  first  two  laws  are  of  particular  interest.  They  state  that  software  cannot 
remain  unchanged  without  becoming  unsatisfactory  to  the  user.  Arguably  the  user’s 
desire  for  change  is  less  about  how  the  software  functions  than  what  functions  it 
performs.  In  short,  the  desire  for  change  is  not  driven  by  worn  out  software  that  can  no 
longer  perform  its  designed-to  tasks,  but  rather  users  demand  software  that  can 
continually  provide  new  and  better  capabilities. 

The  concept  of  increasing  complexity  is  particularly  relevant  when  making  a 
distinction  between  maintenance  and  development.  Qualitatively,  performing 
maintenance  on  an  item  should  not  increase  its  complexity.  Software,  however,  naturally 
increases  in  complexity  when  modified.  The  increase  in  complexity  is  termed  software 
entropy.  Software  entropy,  or  complexity,  increases  at  a  rate  of  one  to  two  percent 
annually  because  of  enhancements  and  bug  fixes  that  occur  on  any  software  system 
(Jones,  2007).  Therefore,  any  software  effort  that  dramatically  increases  the  entropy  or 
complexity  of  the  software  would  not  likely  be  termed  a  maintenance  effort  but  rather  a 
developmental  effort. 
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The  sixth  law  of  evolution  states  that  software  will  become  increasingly  less 
acceptable  over  time  even  if  it  continues  to  function  exactly  as  designed.  This  is  more  a 
statement  about  human  nature  than  about  software.  When  a  software  program  is  used 
extensively,  all  the  functions  it  cannot  perform  are  highlighted  and  dissatisfaction  with 
the  software  increases.  Additionally,  as  software  ages  it  is  invariably  used  in  new  and 
unintended  ways  which  may  highlight  to  the  user  functionality  it  lacks.  An  aircraft  OFF 
is  not  immune  to  this  law.  The  Air  Force  operational  community  actively  engages  in 
identifying  new  functionality  for  its  OFPs. 

The  seventh  law  is  important  in  understanding  the  nature  of  software 
maintenance.  The  first  aspect  of  this  law  is  the  idea  that  a  program  is  “perceived”  to 
decline  in  quality.  While  the  quality  of  the  program  does  not  change  with  time,  the 
perception  of  the  quality  does  change.  When  paired  with  hardware  or  other  software 
programs  for  which  it  was  not  designed  to  interface,  the  software  gives  the  appearance 
that  it  is  “broken”  by  not  operating  as  designed.  The  second  aspect  of  this  law  is  the 
concept  of  a  “changing  operational  environment”.  Taken  out  of  context  this  can  change 
the  scope  and  meaning  of  this  law.  The  operational  environment  an  aircraft  operates  in 
could  change  from  a  benign  air-to-air  threat  (such  as  OPERATION  IRAQI  FREEDOM) 
to  an  intense  air-to-air  threat  (such  as  MiG  alley  in  the  Korean  War).  That  environment, 
however,  is  outside  the  boundary  of  the  software  environment.  Typically,  the  software 
environment  boundary  is  drawn  around  the  actual  hardware  which  runs  the  software. 
Everything  inside  that  boundary  is  the  operational  environment  and  everything  outside 
that  boundary  is  the  external  environment.  Changes  to  the  external  environment  do  not 
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necessarily  change  the  operating  environment  and  therefore  are  outside  the  purview  of 
this  law. 

In-Depth  Examination  of  Software  Maintenance 

These  basic  laws  have  been  translated  into  concrete  definitions  for  the 
maintenance  of  software  by  various  organizations  such  as  The  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE).  The  definitions  are  discussed  below  and  are  summarized 
in  Appendix  A.  Software  engineering,  however,  is  a  discipline  in  its  infancy  when 
compared  to  hardware-related  disciplines.  As  such,  the  terms  used  to  describe  the 
discipline  are  rapidly  evolving  in  both  number  and  meaning.  In  some  instances, 
terminology  does  not  exist  to  properly  describe  software  engineering  activities  while  in 
other  instances  the  terminology  is  sufficiently  vague  (or  rooted  in  the  world  of  hardware) 
that  multiple  meanings  emerge  depending  on  what  organization  or  individual  within  an 
organization  is  using  the  term  (AFMC/A4DC,  2009).  The  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  has  developed  a  standard  glossary  of  software  engineering 
terminology  which  is  described  in  IEEE  Std  610.12-1990. 

In  terms  of  software  maintenance  specifically,  a  standard  terminology  is 
particularly  necessary.  In  a  world  of  well-defined  and  understood  maintenance  practices 
for  hardware,  it  is  easy  to  assume  that  software  maintenance  can  be  handled  under  the 
same  paradigm.  IEEE  Std  12 1 9- 1 992  IEEE  Standard  for  Software  Maintenance  provides 
the  baseline  for  understanding  software  maintenance. 

Software  maintenance  is  broadly  defined  as,  “. . .  the  totality  of  activities  required 
to  provide  cost-effective  support  to  a  software  system”  (Canfora  &  Cimitile,  2000). 


83 


IEEE  Std  610.12-1990  further  defines  software  maintenanee  as,  “The  process  of 
modifying  a  software  system  or  component  after  delivery  to  correct  faults,  improve 
performance  or  other  attributes,  or  adapt  to  a  changed  environment”  (Institute  of 
Electrical  and  Electronics  Engineers,  1990).  It  alternatively  defines  the  maintenance  of 
hardware  as,  “The  process  of  retaining  a  hardware  system  or  component  in,  or  restoring  it 
to,  a  state  in  which  it  can  perform  its  required  functions”  (Institute  of  Electrical  and 
Electronics  Engineers,  1990). 

The  IEEE  definition  views  the  maintenance  of  hardware  and  software  to  be 
separate  and  distinct  undertakings.  The  definitions  indicate  that  software  maintenance  is 
fundamentally  different  than  hardware  maintenance.  As  the  word  maintenance  would 
imply,  hardware  maintenance  is  focused  on  keeping  a  piece  of  hardware  in  good  working 
order  or  returning  a  broken  piece  of  hardware  to  that  same  working  order.  Central  to  this 
notion  is  that  good  working  order  does  not  change  over  time;  the  functionality  of  the 
good  working  order  state  never  changes.  In  contrast,  software  maintenance  includes  not 
only  correcting  faults  to  a  good  working  state  but  also  improving  and  adapting 
performance.  These  two  notions  set  software  maintenance  apart  from  hardware 
maintenance. 

Adaptive  maintenance.  IEEE  further  divides  software  maintenance  into  the 
categories  of  adaptive,  corrective,  and  perfective  maintenance.  Adaptive  maintenance  is 
defined  by  IEEE  610-12.1990  as,”  Software  maintenance  performed  to  make  a  computer 
program  usable  in  a  changed  environment”  (Institute  of  Electrical  and  Electronics 
Engineers,  1990).  This  definition  is  further  refined  by  IEEE  1219-1992  as,  “Modification 
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of  a  software  product  performed  after  delivery  to  keep  a  computer  program  useable  in  a 
changed  or  changing  environment”  (Institute  of  Electrical  and  Electronics  Engineers, 
1992).  As  previously  stated,  the  term  “environment”  refers  to  the  software  environment 
and  not  the  environment  external  to  the  system.  An  example  of  adaptive  maintenance 
could  be  updating  a  word  processing  program  in  response  to  an  upgrade  of  the  operating 
system  from  Windows  Vista  to  Windows  7. 

Corrective  maintenance  is  defined  by  IEEE  610-12.1990  as,  “Maintenance 
performed  to  correct  faults  in  hardware  or  software”  (Institute  of  Electrical  and 
Electronics  Engineers,  1990).  Again,  this  definition  is  refined  by  IEEE  1219-1992  as, 
“Reactive  modification  of  a  software  product  performed  after  delivery  to  correct 
discovered  faults”  (Institute  of  Electrical  and  Electronics  Engineers,  1992).  The 
definition  of  corrective  maintenance  is  one  that  fits  most  closely  with  the  traditional  view 
of  maintenance  which  identifies  and  rectifies  faults  to  return  a  system  to  good  working 
order.  An  example  of  corrective  maintenance  is  the  issuance  of  a  software  patch  that  fixes 
a  bug  which  causes  a  program  to  crash. 

Perfective  maintenance  is  defined  by  IEEE  6 1 0-12. 1 990  as,  “Software 
maintenance  performed  to  improve  the  performance,  maintainability,  or  other  attributes 
of  a  computer  program”  (Institute  of  Electrical  and  Electronics  Engineers,  1990).  IEEE 
1219-192  refines  this  definition  to,  “Modification  of  a  software  product  after  delivery  to 
improve  performance  or  maintainability”  (Institute  of  Electrical  and  Electronics 
Engineers,  1992).  The  ambiguity  that  exists  in  this  definition  leaves  room  to  improperly 
identify  the  system  boundary  considering  “improving  and  adapting  performance”.  The 


85 


definition  refers  specifically  to  the  performance  of  the  software,  and  not  to  the  functions 
the  software  performs.  For  example,  modifying  software  to  perform  a  given  calculation 
more  quickly  would  be  improved  software  performance.  Modifying  software  to  perform 
a  calculation  it  could  not  previously  perform  is  not  improving  software  performance,  but 
would  be  adding  additional  system  functionality.  Figure  19  summarizes  these  three  types 
of  software  maintenance  and  provides  a  typical  example  of  each. 


Software  Maintenance  Categories  (IEEE) 


Software  Maint.  Type 

Example 

Corrective 

Correct  bugs  /  errors 

Perfective 

Faster  cleaner  code 

Adaptive 

Adapt  existing  code  to  new 
processor  environment 

Figure  19.  Types  of  software  maintenance  according  to  IEEE 

In  his  2007  Crosstalk  (The  Journal  of  Defense  Software  Engineering)  article. 
Capers  Jones  offers  23  forms  of  software  modifications  that  fall  within  the  purview  of 
software  maintenance  and  are  listed  in  Table  4.  He  argues  the  two  most  common 
meanings  are  defect  repairs  and  enhancements.  Repairs  and  enhancements  typically  are 
accomplished  via  different  processes  and  sources  of  funding.  However,  funding  sources 
are  combined  by  many  software  companies.  He  cautions  against  the  practice  of 
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aggregation  because  distinguishing  maintenance  efforts  from  enhancement  efforts 


becomes  difficult  (Jones,  2007). 


Table  4.  Kinds  of  software  work  performed  under  the  generic  term  “maintenance”  (Jones,  2007). 


Software  Work  Performed 

Under  the  Generic  Term  "Maintenance" 

1.  Major  enhancements 

(new  features  of  >  20  function  points). 

2.  Minor  enhancements 

(new  features  of  <  5  function  points). 

3.  Maintenance 

(repairing  defects  for  good  will). 

4.  Warranty  repairs 

(repairing  defects  under  formal  contract). 

5.  Customer  support 

(responding  to  client  phone  calls  or  problem  reports). 

6.  Error-prone  module  removal 

(eliminating  very  troublesome  code  segments) 

7.  Mandatory  changes 

(required  or  statutory  changes). 

8.  Complexity  or  structural  analysis 

(charting  control  flow  plus  complexity  metrics  ). 

9.  Code  restructuring 

(reducing  cyclomatic  and  essential  complexity). 

10.  Optimization 

(increasing  performance  or  throughput). 

11.  Migration 

(moving  software  from  one  platform  to  another). 

12.  Conversion 

(changing  the  interface  or  file  structure). 

13.  Reverse  engineering 

(extracting  latent  design  information  from  code). 

14.  Reengineering 

(transforming  legacy  application  to  modern  forms). 

15.  Dead  code  removal 

(removing  segments  no  longer  utilized). 

16.  Dormant  application  elimination 

(archiving  unused  software). 

17.  Nationalization 

(modifying  software  for  international  use). 

18.  Mass  updates  such  as  the  Euro  or  Year  2000  (Y2K)  repairs. 

19.  Refactoring,  or  reprogramming,  applications  to  improve  clarity. 

20.  Retirement 

(withdrawing  an  application  from  active  service). 

21.  Field  service 

(sending  maintenance  members  to  client  locations). 

22.  Reporting  bugs  or  defects  to  software  vendors. 

23. 1  Installing  updates  received  from  software  vendors. 
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The  Naval  Air  Systems  Command  (NAVAIR)  offers  a  more  generalized  list  of 
software  modifieations.  They  assert  the  existence  of  eight  drivers  of  change  to  a  fielded 
software  systems  (Naval  Air  Systems  Command,  2008): 


1 .  Defect  corrections 

2.  Threats 

3.  Policy  or  Doctrine 

4.  Safety 


5.  Interoperability 

6.  Hardware  Changes 

7.  Technology  Insertion 

8.  Functional  Changes 


From  these  drivers  of  change  they  derive  four  basic  sustainment  activities  the  DoD 
performs  on  its  systems  (Naval  Air  Systems  Command,  2008): 

1 .  Improving  performance  and  other  attributes 

2.  Adapting  software  to  new  hardware 

3.  Adding  features  and  functions  to  the  software  to  respond  to  new  user 
requirements  and/or  threat  environments 

4.  Improve  efficiency  and  reliability 

These  activities  are  labeled  software  sustainment  activities,  and  the  same  Navy 
document  equates  “sustainment”  with  “maintenance”.  But  NAVAIR  then  describes  the 
software  life  cycle  as  one  of  development  from  beginning  to  end  (Figure  20),  separating 
software  support  activities  into  either  initial  software  development  or  software 
redevelopment  (Naval  Air  Systems  Command,  2008). 


Software  Support  Activities  and  the 
Acquisition  Life  Cycle 


Pra-Deployment  Software  Support  Stage 
(Initial  Software  Development) 


Support  Stage 

^  (The  RedevolopfTwnt  Phas4) 


Figure  20.  NAVAIR  view  of  the  software  lifecycle  (Naval  Air  Systems  Command,  2008). 
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In  summary,  software  maintenance  is  fundamentally  different  than  hardware 
maintenance.  Most  software  maintenance  efforts  improve  the  software,  while  hardware 
maintenance  is  generally  intended  to  return  the  hardware  to  its  original  functionality. 
Unfortunately,  most  policy  documents  do  not  contain  clear  and  comprehensive 
dictionaries  of  key  terms.  The  definitions  that  do  exist  generally  agree  within  a  single 
level  of  policy  hierarchy  (among  DoD  policy  documents  for  example),  but  there  is  little 
continuity  between  definitions  across  all  levels  of  policy  and  guidance  documents. 

IEEE’s  categories  of  software  maintenance  are  helpful  and  in  use  by  HQ  AFMC, 
but  the  definition  of  “adaptive  software  maintenance”  is  easily  broadened  to  wrongly 
include  significant  performance  improvements.  While  NAVAIR’s  software  maintenance 
categories  are  generally  aligned  with  those  of  IEEE,  confusion  of  terms  exists. 
Post-fielding,  NAVAIR  uses  the  terms  “software  maintenance”,  “software  sustainment”, 
and  “software  developmenf  ’  to  describe  the  same  software  modification  work.  Clear 
definitions  are  needed  for  all  branches  of  the  DoD  and  at  all  levels  of  authority,  from 
Title  10  to  DoD  and  Air  Force  policy  to  low-level  guidebooks. 

Unique  Characteristics  of  OFPs  Among  Software  Types 

The  definitions  for  software  maintenance  from  IEEE  generally  follow  the  eight 
laws  of  software  evolution.  They  tend  to  capture  the  essence  of  the  activities  associated 
with  maintaining  the  long-term  viability  of  a  software  program.  When  applied  by  those 
in  the  various  software  disciplines  they  are  well  understood.  Where  they  fall  short  is  the 
intersection  where  software  and  hardware  meet.  As  highlighted  by  NAVAIR,  not  every 
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software  effort  is  strictly  maintenance;  there  are  other  aspects  of  software  modification 
that  must  be  accounted  for. 


Figure  21  shows  a  spectrum  of  software  and  hardware  products  from  Information 
Technology  (IT)  software  to  hardware.  IT  software  is  used  in  the  retrieval,  storage, 
processing,  and  transmission  of  information.  The  characteristics  of  OFF  software  place  it 
somewhere  between  IT  software  and  hardware.  The  major  distinction  between  OFF  and 
IT  software  is  the  relationship  between  the  hardware  environment  and  the  software.  In 
general,  private  industry  develops  hardware  to  run  IT  software  programs.  But  for  an  OFF 
the  order  is  reversed:  software  is  designed  to  support  hardware.  In  short,  the  output  of  an 
IT  system  is  information  which  is  then  used  by  a  wide  variety  of  external  systems.  In 
contrast,  while  the  output  of  an  OFF  is  also  information,  this  information  is  used  for  a 
single  purpose  by  a  single  external  system:  the  employment  of  weapons  (hardware)  by  an 
aircraft. 


IT  and  OFP  Software  Contrasted 


IT  Software  Avionics  Software 


HW  built  to  run  SW  SW  built  to  run  HW 

Low  cost  per  copy  High  cost  per  copy 

Easy  to  update/patch  Hard  to  update/patch 

High  external  complexity  Low  external  complexity 

Lower  risk?  Higher  risk? 


Hardware 


Figure  21.  IT  and  OFP  software  contrasted 


90 


Secondly,  the  maintenance  of  IT  software  typically  involves  short  timelines  and 
generally  follows  the  IEEE  definitions  of  software  maintenance,  while  a  modified  OFF 
release  takes  several  years  to  develop  and  includes  significant  new  capability.  For 
example,  Microsoft  may  perform  maintenance  on  the  Windows  operating  system  to  adapt 
to  new  processors  or  to  fix  security  vulnerabilities.  The  per-copy  cost  of  Windows  is 
low,  and  these  maintenance  releases  are  made  quickly  when  compared  to  an  OFF  release 
cycle.  In  contrast,  major  OFF  releases  post-IOC  are  often  massive  efforts  performed  at 
great  expense  with  extensive  flight  testing  that  improve  performance  and  add  new 
capabilities.  When  viewed  in  this  context,  it  is  understandable  that  OFF  maintenance  is  a 
confusing  concept.  An  OFF  is  software,  but  it  has  unique  characteristics  which  make  the 
application  of  existing  IT  software  maintenance  definitions  difficult. 

As  an  example  of  how  confusing  definitions  impact  the  implementation  of  policy, 
the  GAO  report  Actions  Need  to  Identify  and  Establish  Core  Capabilities  at  Military 
Depots  found  that  the  Navy  and  Marine  Corps  did  not  include  software  maintenance  as  a 
core  capability  because  they  did  not  “consider  software  maintenance  as  maintenance  in 
the  usual  sense  of  returning  an  item  back  to  its  original  condition”  (Government 
Accountability  Office,  2009).  Rather  than  address  the  source  of  confusion,  the  OSD 
responded  that  the  biennial  core  guidance  defined  depot  maintenance  to  include  all 
aspects  of  software  maintenance.  The  implication  is  that  all  post-deployment  software 
efforts  are  subject  to  Title  10  depot  maintenance  requirements.  As  of  this  writing,  the 
Navy  is  working  to  incorporate  software  maintenance  as  a  core  capability  (AFMC/A4DC, 
2009). 
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Proposed  Definitions 


The  first  step  in  effeetively  communieating  the  source  of  repair  decision  making 
process  (much  less  improving  it)  is  to  establish  a  common  lexicon.  While  existing 
definitions  are  inconsistent  and  overlapping,  we  propose  clear  lines  and  grouping  of 
similar  terms,  as  depicted  in  Figure  22. 


In  common  operational  use,  the  words  “sustainment”  and  “maintenance”  are 
synonymous,  and  refer  to  keeping  a  previously  established  level  or  quality  (JP  1-02 
Department  of  Defense  Dictionary  of  Military  and  Related  Terms,  2007).  The  use  of 
these  words  in  policy  documents  reflects  their  similarity,  and  formal  distinctions  between 
the  two  terms  were  minimal.  Maintenance  is  included  in  sustainment,  along  with  supply 
chain  management  and  other  support  activities.  But  the  terms  are  synonymous  in  terms 
of  work  done  to  repair,  or  overhaul  military  systems.  It  is  therefore  proposed  that  these 
two  terms  be  formally  defined  as  synonymous  and  together  distinguished  from 
“development”. 
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The  authors  propose  the  following  definitions: 


Hardware  Maintenance/Sustainment: 

Material  repair,  overhaul,  upgrading,  or  rebuilding  of  parts,  assemblies, 
or  subassemblies,  and  the  testing  and  reclamation  of  equipment  which 
restores  or  retains  the  originally  designed  functionality. 


Software  Maintenance/Sustainment: 

Reactive  modification  of  a  software  product  performed  after  delivery  to 
correct  discovered  faults,  keep  a  computer  program  usable  in  a  changed 
software  environment  or  improve  its  processing  performance  or 
maintainability. 


Software  Development: 

Modification  of  software  that  adds  new  capabilities,  changes  the 
functional  baseline,  significantly  increases  complexity,  or  responds  to 
significant  new  user  requirements. 


The  advantages  of  these  new  definitions  are: 

1.  They  elearly  distinguish  between  software  and  hardware  maintenance.  This 
allows  policy  to  be  clear  in  its  intent  and  application  toward  any  of  the  defined 
work  types. 

2.  They  separate  modernization  efforts  from  maintenance  efforts.  As  indicated  in 
Figure  15,  current  processes  do  not  allow  for  funding  other  than  operations  and 
maintenance.  By  providing  a  stand-alone  definition  of  software  modernization,  it 
will  now  be  possible  for  post-deployment  software  efforts  to  use  appropriate 
sources  of  funding. 

3.  The  definition  of  software  modernization  uses  specific  terminology  which  allows 
a  more  systematic  identification  of  work  type. 
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The  disadvantages  of  the  new  definitions  are: 


1 .  Separating  software  development  from  software  maintenance  forces  the 
categorization  of  an  overall  software  effort  as  either  maintenance  or  development, 
which  may  be  difficult  as  aspects  of  both  development  and  maintenance  may  be 
present.  A  model  is  proposed  in  the  next  chapter  as  an  aid  in  making  this 
determination. 

2.  The  ambiguity  that  exists  with  current  definitions  allows  for  flexibility  in  their 
application  to  law,  policy,  and  funding. 

The  need  for  accurate  definitions  to  describe  work  that  is  currently  accomplished 
on  combat  aircraft  OFPs  is  urgent.  As  evidenced  by  NAVAIR’s  recent  move  to  include 
software  modification  as  a  core  logistics  capability,  a  simple  misunderstanding  of 
definitions  could  result  in  large  expenditures  on  unplanned  organic  maintenance 
infrastructure.  Separating  maintenance  from  development,  however,  is  not  without  its 
challenges.  Challenges  such  as  securing  the  appropriate  funding  and  overcoming  the 
inertia  of  the  status  quo  might  impede  the  adoption  of  new  definitions.  Those  challenges 
are  outside  the  scope  of  this  study,  however,  and  the  next  chapter  proposes  a  means  for 
categorizing  OFP  modification  as  either  maintenance  or  development. 
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VI.  OFP  Sustainment:  Maintenance  or  Development? 


The  final  chapter  will  conclude  with  a  recommendation  about  who  should 
perform  OFP  updates:  the  government,  the  private  sector,  or  a  mix.  But  first,  it  must  be 
determined  if  OFP  development  falls  under  the  umbrella  of  Title  lO’s  requirement  for  a 
government  depot  maintenance  capability.  If  it  can  be  shown  that  some  OFP  modification 
is  not  a  maintenance  or  repair  action,  then  Title  10  does  not  apply  and  the  DoD  is  free  to 
select  a  work  source  for  OFPs  based  on  other  factors  such  as  cost-effectiveness.  We  will 
first  examine  examples  of  hardware  and  software  maintenance,  then  consider  software  in 
particular. 

As  previously  stated,  AFMC  currently  separates  software  maintenance  into  four 
categories  adopted  from  industry:  corrective,  perfective,  preventative,  and  adaptive 
(AFMC/A4DC,  2009).  Figure  23  provides  examples  of  software  work  in  each  of  these 
categories  as  the  authors  envision  them.  The  last  column  contains  hardware  analogies  for 
each  of  these  categories,  although  hardware  maintenance  is  not  formally  categorized  in 
this  manner. 
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Categories  of  Software  Work  In  Use  by  AFMC 


Maintenance 

Development 

Work  Type 

Software 

Hardware 

Analogy 

Software 

Hardware 

Analogy 

Corrective 

•  Correct  bugs  /  errors 

•  Crack  repair 

N/A 

•  New  wings  for  A-10 

Preventive 

N/A 

•  Inspections, 
stiffeners 

N/A 

N/A 

Perfective 

(improving) 

•  Faster  cleaner  code 

•  Improve 
maintainability  via 
more  access  panels 

•  New  capability 

•  New  engines  for 
greater  speed 

Adaptive 

•  Adapt  existing  code  to 
new  processor 

environment 

N/A 

•  OFP  updated  to 
support  new 
weapon  for  new 
threat  env. 

•  New  jet  (F-22)  for 
changed  threat 

env. 

Figure  23.  Categories  of  software  work  in  use  by  AFMC 


Several  observations  about  the  line  between  software  maintenanee  and 
development  are  now  made  using  Figure  23.  Corrective  modifications  are  normally 
maintenance.  Software  may  be  corrected  to  fix  bugs  which  prevent  the  software  from 
performing  an  intended  function.  Likewise,  a  hardware  system  undergoes  corrective 
maintenance  to  repair  a  cracked  or  worn  component.  However,  there  exists  corrective 
action  which  is  development.  For  example,  as  the  A- 10  ages,  its  wings  developed  cracks 
requiring  the  design  of  an  entirely  new  wing  built  by  a  third  party.  Preventive  work  is 
almost  always  a  hardware  maintenance  action  because  software  does  not  wear  out. 

The  last  two  categories,  perfective  and  adaptive,  are  the  most  difficult  to  divide 
into  maintenance  and  development.  If  perfective  maintenance  improves  software  or 
hardware,  then  any  work  that  adds  new  capability  could  be  construed  as  perfective 
maintenance.  However,  a  line  must  be  drawn  between  perfecting  the  software  or 
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hardware  for  its  current  function  and  improving  the  software  or  hardware  by  adding 
significant  new  capability.  For  example,  modifying  an  OFF  to  achieve  the  same 
functionality  more  efficiently  by  writing  cleaner  code  would  appropriately  be  called  a 
maintenance  action.  Likewise,  minor  changes  to  hardware  that  improve  the 
maintainability  could  be  considered  maintenance.  But  modifying  an  OFF  to  add 
significant  new  capability  as  a  result  of  new  user  requirements  is  more  appropriately 
labeled  “development”,  even  though  the  OFF  is  being  perfected  or  improved  in  a  broad 
sense. 


Adaptive  maintenance  is  likewise  difficult  to  categorize.  The  key  is  to  identify 
the  boundary  of  the  environment  to  which  an  entity  is  adapted.  If  software  must  be 
operated  on  a  new  chip,  maintenance  action  is  performed  because  of  this  change  in  the 
hardware  that  runs  the  software.  But  if  our  enemies  design  a  new  way  of  building 
hardened  bunkers,  the  modification  of  an  OFF  to  support  a  new  bunker-busting  weapon  is 
development.  Because  the  threat  environment  changed,  some  might  argue  that  this  OFF 
modification  is  “adaptive”.  But  taken  to  its  logical  conclusion,  this  reasoning  would 
make  the  development  of  every  military  system  a  “maintenance”  action  because  the 
United  States  is  merely  adapting  to  the  changed  threat  environment  be  creating  new 
weapons.  So  the  environment  boundary  must  be  drawn  closer  to  apply  the  label 
“adaptive  maintenance”. 
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Characterizing  OFF  Modifications:  Qualitative  Model 

Now  that  a  definition  of  “software  maintenance”  has  been  established,  the  focus  is 
narrowed  to  aircraft  OFPs.  OFF  maintenance  is  contrasted  with  OFF  development.  As 
stated  previously,  if  OFP  modification  is  determined  to  be  development  and  not 
maintenance,  then  the  organic  capability  requirements  of  Title  10  do  not  apply. 

Currently,  all  OFP  modification  not  accompanied  by  a  hardware  change,  and 
much  OFP  work  associated  with  hardware  change  is  classified  as  maintenance  by  HQ 
AFMC  (AFMC/A4DC,  2009).  Today,  the  SORAP  decision  accomplished  prior  to  IOC 
normally  states  that  OFP  work  on  combat  aircraft  supports  a  core  capability,  and  this 
classification  may  remain  for  the  life  of  the  system.  An  alternative  to  this  current  practice 
would  be  to  make  early  assessment  of  whether  OFP  modification  is  development  or 
maintenance  for  each  major  release.  To  this  end,  a  model  for  aiding  in  this  decision  is 
proposed.  By  using  a  model,  OFP  modification  work  can  be  properly  classified  and 
accurately  considered  under  the  provisions  of  Title  10  and  DoD  policy. 

Key  to  developing  a  process  to  identify  the  nature  of  an  OFP  modification  is  the 
characteristics  of  software  development  versus  software  maintenance.  Those 
characteristics  can  then  be  used  to  evaluate  software  work  and  properly  categorize  it. 

OFP  characteristics  useful  in  performing  this  examination  are  listed  in  Figure  24.  These 
characteristics  were  identified  by  analysis  of  current  definitions  and  policy,  the  input  of 
interviewed  depot  engineers,  and  the  experience  of  the  authors  in  operational  use  of 
various  OFPs. 
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AFMC/A4D  currently  classifies  software  modification  as  development  only  if  it  is 
accompanied  by  a  hardware  modification  (AFMC/A4DC,  2009).  This  paradigm,  that 
hardware  ehanges  drive  software  development,  causes  some  software  development  that  is 
not  aeeompanied  by  new  hardware  to  be  mis-elassified  as  maintenanee. 

For  example,  with  no  change  to  hardware,  the  F-15  radar  OFF  eould  be  modified 
to  allow  signifieant  new  capability  such  as  target  identification  modes,  increased  number 
of  traeked  targets,  or  new  data  link  modes  to  existing  weapons.  Sueh  work  would  result 
in  a  signifieant  increase  in  OFF  complexity  and  yet  not  be  assoeiated  with  a  hardware 
ehange.  While  the  seeond  law  of  software  evolution  states  that  there  will  be  a  natural 
inerease  in  eomplexity  with  changes  to  software,  it  is  not  referring  to  signifieantly 
inereased  complexity  that  comes  from  a  development  effort  to  add  new  eapability. 

Finally,  OFF  modifieation  work  ean  be  eategorized  as  maintenance  or 
development  based  on  the  baseline  which  is  affected.  This  idea  was  proposed  by  Lt  Col 
Joe  Jarzombek’s  in  his  1997  Crosstalk  Article: 


We  ean  formally  elarify  the  differences  among  development,  modifieation, 
and  maintenanee  activities  by  delineating  software  support  aetivities 
among  funetional,  allocated,  and  product  baselines.  For  example,  to  fix 
software  bugs  to  comply  with  existing  baselines  or  specifieations  eould  be 
eonsidered  maintenance  (although  many  would  argue  that  eode  ehanges 
are  ehanges  to  product  baselines,  and  as  such  are  modifieation  rather  than 
maintenance  activities).  To  ehange  software  design  or  interfaces  among 
modules  is  clearly  a  modifieation  aetivity,  sinee  it  impaets  produet  or 
allocated  baselines.  To  add  new  eapabilities  outside  the  seope  of  the 
existing  functional  baselines  would  be  development.  (Jarzombek,  1997) 
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According  to  a  2009  briefing  by  the  830*  Aircraft  Sustainment  Group  at  Robins 
Air  Foree  Base,  “the  F-15  is  . .  .currently  undergoing  the  most  eomplex  and  lethal 
upgrades  in  its  history”  (Reed,  2010).  This  hardly  fits  the  paradigm  envisioned  by  Title 
10  eore  laws  whereby  a  system  is  in  high  flux  during  development  but  then  generally 
reaches  steady  state  after  it  is  in  use  operationally,  and  requires  only  maintenance.  The 
F-15,  now  over  30  years  old,  is  an  example  of  an  old  jet  gaining  signifieant  new 
capabilities.  And  the  F-15’s  OFF  is  being  modified  to  integrate  the  information  flowing 
from  and  to  these  new  systems. 

Additional  eharaeteristies  that  operational  experience  has  shown  to  differentiate 
software  maintenance  from  development  are: 

•  Amount  of  flight  testing  required 

•  Amount  of  training  required  for  the  operator  of  the  new  OFF 

•  Rate  at  whieh  modified  OFFs  are  released  to  the  field 

The  testing  benehmark  is  important  because  a  large  test  effort  is  a  strong  indieator 
that  something  is  undergoing  development.  Modification  to  an  OFF  requiring  568  test 
sorties  is  not  a  maintenance  effort.  Yet  such  was  the  ease  with  the  F-15C  Suite  5  OFF 
(Gatlin,  Spain,  Stands,  &  White,  2007).  Additionally,  new  technical  orders  and/or  new 
operator  training  and  certifieation  on  an  OFF  are  typieally  required  only  when  new 
funetionality  is  added  to  the  system — another  indieator  of  development 

Finally,  a  rapid  release  rate  is  indieative  of  maintenance  action  while  significant 
time  between  releases  indieates  that  more  than  bug  fixes  are  occurring. 
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The  authors  propose  a  qualitative  model  (Figure  24)  that  eharacterizes  an  OFF  by 
the  following  eight  basie  charaeteristies: 

1 .  Amount  of  new  requirements  ineorporated 

2.  Baseline  affeeted  by  the  modifieation 

3.  Amount  of  new  capabilities  incorporated 

4.  Net  change  in  complexity 

5.  Testing  required  to  field  the  OFF 

6.  Level  of  training  and  documentation  required  to  operate  the  OFF 

7.  Whether  the  OFF  modification  is  accompanying  a  hardware  change 

8.  Time  interval  between  the  current  OFF  release  and  the  previous  release 

Figure  24  lists  each  of  the  eight  characteristics  and  then  qualitatively  defines  what 
makes  that  characteristic  of  the  OFF  modification  either  maintenance  or  development. 
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OFP  Modification:  Maintenance  or  Development? 


Factor 

Maintenance 

Development 

New  requirements? 

•  No 

•  Yes 

Baseline  affected 

•  Product 

•  Functional 

Significant  new  capability? 

•  No 

•  Yes 

Complexity  of  new  OFP 
version 

•  <=  previous  version 

•  Greater  than  previous  version 

Testing  burden 

•  Bench  /  lab  testing 

•  Flighttesting  (DT&E,  OT&E) 

NewTraining& 
Documentation  Required 

•  No 

•  Yes 

OFP  accompanied  by 
hardware  change? 

•  Might  be  maintenance 

•  Likely  development 

Release  Rate 

•  12-18  months 

•  2+ years 

Funding  used 

•  3400  (O&M) 

•  3600  (R&D) 

•  3010  (Procurement) 

Source  of  work 

•  Mostly  government 

•  Mostly  private 

(required  by  Title  10) 

(not  core) 

Core  capability  required  by 
Title  10? 

•  Yes 

•  No 

Figure  24.  Qualitative  model  for  OFP  work  classification 
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Qualitative  Model  Applied  to  F-15C  OFF  Suite  4 


The  research  team  evaluated  the  characteristics  of  the  F-15C’s  Suite  4  OFF  with 
the  previously  presented  qualitative  model.  As  shown  in  Figure  25,  Suite  4  flagged  all  of 
the  qualitative  indicators  of  development  work  even  though  25  years  had  passed  since 
IOC.  Yet,  the  work  was  categorized  “core”  by  AFMC  and  designated  a  maintenance 
effort. 


F-15C  Suite  4  OFF  (25  years  after  IOC) 


Factor 

^  Maintenance 

Development  ^ 

X 

•  Support  AIM-120  C5 

New  requirements? 

•  SupportAIM-9X 

•  Helmet  mounted  display 

•  New  radar 

Baseline  affected 

•  Functional 

•  New  ID  modes 

Significant  new  capability? 

•  New  weapons 

•  New  pilot  displays 

Complexity  of  new  OFP 
version 

•  >  previous  version 

Testing  burden 

•  325  flights  (DT&OT) 

NewTraining& 

•  New  operator's  manual 

Documentation  Required 

•  New  simulator  software 

OFP  accompanied  by 

•  New  radar 

hardware  change? 

•  New  weapons 

Release  Rate 

•  2+ years 

Were  core  laws  applied? 

Yes,  but  model  indicates^^ 

Figure  25.  F-15C  Suite  4  qualitative  assessment 
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The  attributes  in  the  model  (Figure  24)  provide  the  means  for  qualitatively 
evaluating  an  OFF  to  determine  whether  a  software  effort  is  most  likely  eategorized  as 
maintenanee  or  development.  The  main  disadvantage  of  the  qualitative  model  is  that  it  is 
subjeet  to  interpretation.  Subjeetive  assessments  are  not  ideal  for  categorizing  a  software 
effort  that  has  attributes  of  both  maintenance  and  development.  A  quantitative  means  for 
assessing  an  OFF  is  therefore  desirable. 

Quantitative  OFF  Assessment  Tool  lOuOAT) 

The  QuOAT  is  a  tool  for  converting  qualitative  assessments  into  quantitative 
measures.  This  is  accomplished  by  weighting  eight  OFF  attributes  determined  to  be 
indicators  of  software  modification  work  classification,  as  previously  discussed. 

The  attributes  in  the  QuOAT  model  are  weighted  within  an  attribute  category  but 
not  across  attribute  categories.  Each  attribute  receives  equal  weighting  in  the  overall 
assessment.  No  single  category  receives  more  weight  compared  to  other  categories.  This 
approach  was  chosen  because  no  attribute  was  found  to  contribute  to  the  classification  of 
OFF  work  more  than  any  other  attribute. 

Although  the  QuOAT’ s  output  is  a  quantitative  value  representing  the  degree  to 
which  an  OFF  modification  is  either  development  or  maintenance,  the  model  is  intended 
as  an  aide  in  source  of  repair  decisions  and  not  the  primary  decision  making  tool. 

The  attribute  weights  in  the  QuOAT  ranges  from  0  to  100.  A  “0”  score  in  any 
attribute  category  strongly  indicates  that  the  OFF  modification  work  has  characteristics  of 
maintenance.  Conversely,  a  100  score  in  any  attribute  category  is  a  strong  indicator  that 
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the  OFP  attribute  is  related  to  a  development  effort.  The  other  two  weighting  options  are 
45  and  55  and  are  are  intentionally  close  to  the  midpoint  value  of  50.  Values  in  this 
range  indicate  a  weak  discriminator  of  work  classification.  Using  the  45  and  55 
weighting  options  eliminates  over-emphasis  of  attributes  that  do  not  clearly  indicate  OFP 
work  as  being  either  maintenance  or  development.  The  0-100  scale  was  chosen  to 
provide  a  large  gap  between  an  attribute  category  scored  as  maintenance  and  one  scored 
as  development.  A  0-10  weighting  scale  provides  an  identical  outcome  but  makes  the 
classification  of  an  OFP  less  obvious. 
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The  implementation  of  the  QuOAT  is  a  four  step  proeess  with  Table  5  as  a  guide: 


1 .  Make  a  qualitative  assessment  of  the  OFF  modifieation  work  within  eaeh  of  the 
eight  attribute  eategories  based  on  the  deseriptive  statements  in  Table  5. 

a.  The  Requirements,  Capability,  Complexity,  and  Release  deseriptive 
statements  are  comparative  assessments  against  the  previous  OFF  release. 

b.  The  Baseline,  Testing,  Training/Documentation,  and  Hardware  Change 
descriptive  statements  are  stand  alone  assessments  of  the  OFF  effort  under 
review. 

2.  Assign  each  attribute  category  a  value  of  0,  45,  55,  or  100  based  on  results  from 
step  1. 

3.  Sum  the  values  across  the  eight  attribute  categories  to  calculate  a  total. 

4.  Classify  the  OFF  effort  as: 

a.  Maintenance  :  <360 

b.  Development :  >  440 

c.  Ambiguous  :  360  -  440. 

OFFs  in  this  region  require  some  other  means  of  categorizing  the  work. 


Table  5.  Guide  to  a  quantitative  OFF  assessment 


Value 

Requirements 

Baseline 

Capability 

Complexity 

Testing 

Training 

Docs 

Hardware 

change 

Release 

interval 

0 

No  new 
Requirements 

Only  product 
affected 

No  new 
capability 

No  Change/ 
Decrease 

Bench  Testing 

No 

No 

<12  months 

45 

Few  new 
requirements 

Productand/or 
allocated  affected 

Few  new 
capabilities 

Minimal 

increase 

Minimal 
Flight  Testing 

12-18  months 

55 

Many  new 
requirements 

Only  allocated 
affected 

Many  new 
capabilities 

Large 

Increase 

Moderate 
Flight  Testing 

18-24  months 

100 

Extensive  new 
requirements 

Functional 

affected 

Extensive  new 
capabilities 

Extensive 

Increase 

Significant 
Flight  Testing 

Yes 

Yes 

>24  months 
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QuOAT  Model  Description  and  Results 


A  scoring  of  various  OFPs  is  depicted  in  Figure  26.  These  data  were  obtained  via 
interviews  of  individuals  with  in-depth  understanding  of  the  OFF  modification  process. 
Each  interviewee  was  provided  a  list  of  questions  based  on  Table  5  and  asked  to  assess 
their  particular  OFF  modification  effort.  These  questions  can  be  found  in  Appendix  F : 
QuOAT  Interview  Questions.  Those  interviewed  were  not  told  how  each  value  related  to 
the  maintenance/development  spectrum.  This  method  was  chosen  to  avoid  prejudicing 
the  results  towards  the  interviewee’s  preconceived  opinion  about  how  OFP  workload 
should  be  categorized.  The  results  obtained  by  evaluating  the  interview  data  with  the 
QuOAT  perfectly  matched  the  qualitative  assessments  the  interviewees  had  already 
conducted.  This  validated  the  QuOAT’s  ability  to  quantify  qualitative  assessments. 


QuOAT  Analysis  of  OFP  Modifications 


F-22  Increment  3.1 

F-22  Increment  2.3 

F-15E  Suite  7E 

F-15E  Suite  6E 

F-15C  Suite  6C 

F-16BLK30SCU8 

B-1SB13 

A-IOC  Suite  6 


Maintenance  Ambiguous 


Development 

I  Requirements 
I  Baseline 
I  Capability 
I  Complexity 
■  Testing  Effort 
iTrng  &  Documentation 
I  Hardware  Changes 


I  Release  Interval 


z: 


0  100  200  300  400  500  600  700  800 


Figure  26.  Quantitative  analysis  of  OFP  modincations 
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Application  of  the  model  to  two  different  F-22  OFF  releases  serves  as  a  good 
example  of  the  tool’s  utility.  F-22  Increment  2  Update  3  OFF  is  managed  by  the  F-22 
program  offiee’s  sustainment  division  (Feet,  2010).  QuOAT  output  for  that  OFF  release 
was  390.  This  result  was  loeated  in  the  ambiguous  elassification  zone  but  slightly 
favored  a  “maintenance”  classification.  In  contrast,  the  F-22  Increment  3.1  OFF  is 
managed  by  the  program  offiee’s  modernization  division  (Feet,  2010).  QuOAT  assigned 
that  OFF  a  value  of  710,  well  above  the  minimum  of  440  required  for  categorization  as 
development.  In  this  case,  the  organizational  divisions  of  the  F-22  program  office  refleet 
the  nature  of  the  OFF  modifieation  being  managed  (as  eharaeterized  by  the  model). 

Minor  updates  to  previous  releases  are  labeled  “sustainment”  and  major  updates  are 
labeled  “modernization”  (development). 

The  information  obtained  from  QuOAT  is  most  promising  for  its  potential  to 
influenee  deeisions  about  the  sustainment  of  software.  QuOAT  provides  decision  makers 
a  means  to  assess  whether  a  OFF  modification  effort  lies  within  the  boundaries  of 
Title  10  sustainment  law  or  without.  Following  this  determination  another  decision 
remains:  ehoosing  between  publie  and  private  seetors  for  the  modification  work. 
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VII.  Public  and  Private  Sustainment  Options  for  OFPs 


With  definitions  established,  law  and  policy  reviewed,  and  models  developed,  the 
foundation  is  set  for  a  consideration  of  how  to  allocate  the  OFF  modification  work  of 
Air  Force  manned  combat  aircraft:  to  the  public  sector,  to  the  private  sector,  or  with  a 
public-private  partnership. 

The  early  stages  of  this  determination  rely  on  definitions.  Because  Title  10  calls 
all  software  maintenance  “depot-level  maintenance”,  if  OFF  modification  post-IOC 
matches  the  definition  of  software  maintenance,  then  it  is  a  core  candidate  and  the 
majority  of  the  work  may  be  allocated  to  the  public  sector  via  core  capability  policy.  On 
the  other  hand,  if  OFF  modification  is  classified  as  software  development,  core  capability 
laws  do  not  apply  and  the  DoD  will  have  greater  flexibility  in  allocating  the  work 
according  to  other  priorities,  such  as  cost-effectiveness. 

A  second  factor  in  allocating  the  work  is  grouping  or  binning  the  OFF  work. 
Currently,  all  OFF  modification  work  for  a  given  aircraft  type  is  considered  in  one  large 
chunk.  This  work  is  normally  categorized  as  core — contributing  to  an  organic  OFF 
capability.  Another  option  is  to  consider  each  OFF  release  for  a  given  aircraft  type 
separately,  determining  each  to  be  either  maintenance  or  development  by  applying  a 
model  similar  to  the  one  summarized  in  Figure  24.  As  an  example  of  extreme  binning,  a 
third  option  would  be  to  label  each  separate  line  of  code  as  maintenance  or  development, 
and  allocate  the  labor  hours  according  to  the  proportion  of  maintenance  lines  of  code  to 
development  lines  of  code.  This  third  option  is  impractical  and  is  only  mentioned  as  the 
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extreme  opposite  of  current  practice.  These  three  binning  options  for  the  parsing  of  OFF 
workload  are  depicted  in  Figure  27. 
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Figure  27.  OFP  binning  options 


The  twin  issues  of  definitions  and  OFP  binning  are  now  applied  by  way  of 
example:  F-22  OFP  development.  As  stated  earlier,  OFP  work  managed  by  the  F-22 
program  office  is  separated  into  two  branches:  sustainment  and  modernization. 

Increment  2,  the  first  major  OFP  update  following  IOC  in  2005,  is  managed  by  the 
sustainment  branch.  And  this  makes  sense  as  much  of  the  work  involves  correcting 
deficiency  reports  which  document  areas  in  which  the  OFP  is  not  operating  as  planned  or 
originally  desired.  Meanwhile,  work  on  the  next  major  release,  dubbed  increment  3.1,  is 
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managed  by  the  modernization  branch  because  it  involves  significant  new  development. 
Increment  3.1  began  with  significant  new  requirements  and  a  new  Capability  Production 
Document  and  added  significant  new  capability  to  the  F-22.  This  OFP  release  involves  a 
multi-year  development  effort,  hundreds  of  flight  tests,  and  adds  new  features  and 
capabilities  to  the  aircraft  requiring  new  operator  training  and  changes  to  the  operator’s 
manual. 

The  management  division  between  the  sustainment  effort  for  the  previous  OFP 
release  (Increment  2)  and  the  modemization/development  effort  for  the  next  major 
release  (Increment  3.1)  reflects  the  nature  of  the  software  modifications  being  made.  But 
while  the  models  support  this  division,  the  F-22  OFP  source  of  repair  decision  signed  in 
2007  classified  all  F-22  OFP  modification  workload  as  a  core  capability  candidate.  By 
legal  implication,  this  classification  declares  all  F-22  OFP  modification  work  to  be 
“software  maintenance”. 

To  avoid  the  misclassification  of  OFP  work,  we  recommend  that  OFPs  for  a  given 
aircraft  type  be  considered  release  by  release  (binning  option  #2  in  Figure  27).  This 
would  require  a  source  of  work  decision  for  each  major  OFP  release,  but  would  allow 
management  decisions,  workload  allocation,  and  funding  sources  to  reflect  reality:  new 
OFP  releases  are  often  developmental  efforts. 

Public-Private  Partnering 

A  hybrid  depot  maintenance  option  has  grown  into  law  and  policy.  Public-private 
partnering  mitigates  the  tension  between  the  classification  of  OFP  work  as  supporting  a 
core  capability  and  the  reality  that  much  of  the  work  is  actually  development  and  rightly 
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funded  by  development  money.  “Public-private  partnering,”  a  formal  term  established  by 
Title  10  section  2474  in  1998,  is  designed  to  increase  efficiency  by  allowing  equipment 
and  facility  sharing  between  public  and  private  sectors.  Partnering  also  intends  to 
leverage  the  advantages  of  each  sector  by  using  both  in  the  sustainment  of  military 
systems. 

Partnering  relationships  between  government  and  private  depots  were  first 
encouraged  in  the  National  Defense  Authorization  Act  of  1995.  But  other  parts  of  the 
law,  such  as  the  core  requirement  and  50/50  funding  law,  were  barriers  to  the 
establishment  of  partnerships.  Subsequent  NDAA’s  provided  increasing  detail  on 
partnerships,  permitting  the  sharing  of  equipment  and  facilities  and  allowing  receipts 
from  partnerships  to  be  credited  to  government  depot  accounts  (Vitasek,  Cothran,  & 
Turner,  2007). 

Partnering  agreements  exist  in  two  basic  categories.  First,  Workshare/Teaming 
arrangements  allow  the  government  and  contractors  to  each  perform  their  share  of  the 
workload  and  be  paid  separately  by  the  government  customer  (Vitasek,  Cothran,  & 
Turner,  2007).  For  example,  a  private  depot  might  be  paid  to  maintain  30%  of  F-35 
engines  while  the  government  depot  maintains  70%  of  the  engines.  Or  the  work  may  be 
split  between  disassembly/inspection  and  reassembly/testing. 

The  second  category  of  partnering  is  Direct  Sales  arrangements.  The  contractor  is 
paid  by  the  government  but  sub-contracts  to  the  government  depot  to  actually  perform  the 
maintenance  (Vitasek,  Cothran,  &  Turner,  2007).  In  essence,  the  government  depots  act 
as  sub-contractors  to  private  industry. 
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The  key  advantage  of  partnering  is  that  contractor  work  performed  in  a 
government  facility  can  be  counted  toward  core  labor  hours  (Vitasek,  Cothran,  &  Turner, 
2007).  Partnering  ensures  that  core  laws  are  satisfied  while  keeping  both  industry  and 
government  employed  and  current  in  defense  systems.  Commercial  best  practices  are 
leveraged  while  maximizing  use  of  government  facilities  and  equipment  (Vitasek, 
Cothran,  &  Turner,  2007).  As  the  Undersecretary  of  Defense  for  Logistics  and  Materiel 
Readiness  stated,  “DoD's  goals  for  depot  maintenance  public  private  partnerships  are: 
more  responsive  product  support,  better  facility  utilization,  reduced  cost  of  ownership, 
and  more  efficient  business  processes”  (Bell,  2007) 

Public-private  partnerships  are  increasingly  common,  as  shown  in  Figure  28.  In 
the  case  of  combat  aircraft  OFPs,  private  companies  who  develop  the  aircraft  are  the 
most  skilled  in  modifying  the  OFP.  Partnering  allows  the  government  to  become  skilled 
in  OFP  modification  for  eventual  ownership  of  the  process.  Reasons  for  this  move  from 
private  to  public  OFP  modification  over  the  life  of  an  aircraft  are  addressed  in  the  next 
chapter. 


Figure  28.  Growth  of  Public-Private  Partnerships  (The  Joint  Maintenance  Activities  Group,  2007) 
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The  three  options  for  OFF  modification  workload  allocation  are  compared  and 
contrasted  in  Figure  29.  While  the  context  for  work  accomplished  under  any  of  the  three 
options  is  generally  “depot  maintenance,”  these  same  options  exist  for  allocation  of 
development  work.  However,  as  OFF  modification  on  Air  Force  aircraft  is  typically 
designated  a  core  workload,  OFF  development  post-IOC  is  allocated  to  one  of  these  three 
options  in  a  “software  maintenance”  context. 


OFP  Modification:  Workload  Allocation  Options 
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Figure  29.  Pros  and  Cons  of  Public  and  Private  Depots 


Summary:  Public  and  Private  Sustainment  Options  for  OFPs 

Workload  associated  with  the  modification  of  USAF  combat  aircraft  OFFs  today 
is  usually  designated  core  and  is  therefore  subject  to  Title  10  core  logistics  requirements. 
Workload  allocation  is  normally  not  re-categorized  for  subsequent  OFF  releases.  An 
OFF  workload  is  generally  classified  as  core  at  the  beginning  of  an  aircraft  program  and 
remains  core  for  the  life  of  the  aircraft. 
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The  organization  of  some  aircraft  program  offices  reflects  the  reality  that  much 
OFF  modification  is  development/modemization  and  not  maintenance.  Sources  of 
funding  used  for  OFF  modification  work  vary  greatly  from  aircraft  to  aircraft,  as 
considered  in  previous  chapters.  Some  use  mostly  development  money  while  others  rely 
on  operations  and  maintenance  funds. 

Fartnering  agreements  between  public  depots  and  private  contractors  are 
increasing  in  number.  Such  agreements  allow  the  leveraging  of  the  strengths  of  both  the 
public  and  private  sectors  while  satisfying  Title  10  core  logistics  laws.  But  should  such 
arrangements  be  used  for  OFF  development  as  well  as  maintenance?  We  answer  this 
question  through  several  summary  conclusions  and  recommendations. 
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VIII.  Conclusions  and  Recommendations 


The  three  primary  objectives  of  this  research  were  to: 

1 .  Better  understand  a  complex  web  of  law,  policy,  and  practice  regarding  the 
application  of  Title  10  depot  maintenance  requirements. 

2.  Propose  a  common  dictionary  of  terms  for  use  in  policy  and  regulations. 

3.  Propose  a  more  flexible  model  for  avionics  software  source  of  repair 
decisions. 

To  meet  these  objectives,  the  following  subjects  were  researched  and  analyzed: 

•  Title  10  law  and  resulting  DoD  and  Air  Force  policies. 

•  Fundamental  differences  between  hardware  and  software  sustainment. 

•  How  software  sustainment  should  be  distinguished  from  software 
modemization/development. 

•  Public-private  partnerships  in  the  context  of  software  sustainment. 

With  this  foundation,  the  following  conclusions  and  recommendations  are  made: 

#1  -  Institute  a  Common  Dictionary 

As  a  first  step  in  unraveling  the  complex  web  of  core  logistics  law  and  policy 
confusion,  we  recommend  the  proposed  common  taxonomy  of  software  maintenance  and 
development  terms,  proposed  in  this  research,  be  universally  established  within  the  DoD. 
A  clear,  common,  and  consistent  glossary  regarding  core  capability  determination  should 
be  included  in  DoD  and  Air  Force  policy  documents  and  downstream  handbooks  and 
guidebooks.  Acquisition  education  should  also  include  clear  instruction  on  these 
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definitions  so  that  future  acquisition  professionals  have  the  tools  required  to  make 
consistent  decisions  about  the  allocation  of  OFF  workloads. 


The  following  definitions  are  proposed: 

o  Hardware  Maintenance/Sustainment: 

■  Material  repair,  overhaul,  upgrading,  or  rebuilding  of 
parts,  assemblies,  or  subassemblies,  and  the  testing  and 
reclamation  of  equipment  which  restores  or  retains  the 
originally  designed  functionality. 

o  Software  Maintenance/Sustainment: 

■  Reactive  modification  of  a  software  product  performed 
after  delivery  to  correct  discovered  faults,  keep  a  computer 
program  usable  in  a  changed  software  environment  or 
improve  its  processing  performance  or  maintainability 

o  Software  Modernization  (Development  after  initial  release): 

■  Modification  of  software  that  adds  new  capabilities, 
changes  the  functional  baseline,  significantly  increases 
complexity,  or  responds  to  significant  new  user 
requirements. 

#2  -  Use  QuOAT  to  Assess  Each  OFF  Release  as  Maintenance  or  Development 

Second,  we  recommend  accomplishing  an  assessment  of  each  major  OFF  release. 
Military  aircraft  OFF  development  is  often  not  software  maintenance  and  the  workload 
associated  with  a  given  OFF  should  not  be  designated  “core”  by  default.  OFF 
development  often  involves  new  user  requirements,  significant  new  capability,  and 
requires  extensive  developmental  and  operational  testing  prior  to  release.  Each  major 
OFF  release  should  be  classified  as  development  or  maintenance  according  to  the 
common  lexicon  aided  by  the  qualitative  model  and  quantitative  (QuOAT)  assessment 
tool  proposed  in  this  research. 
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The  division  of  labor  between  public  and  private  sectors  might  be  changed 
significantly  by  these  first  two  recommendations.  However,  several  advantages  exist. 
First,  the  official  classification  given  to  OFF  work  will  more  closely  match  the  nature  of 
the  work  being  done  and  type  of  funding  employed.  A  major  OFF  release  that  is  mostly 
development  work  will  be  classified  as  development,  and  core  maintenance  laws  would 
not  apply.  The  DoD  and  its  program  managers  would  be  afforded  greater  flexibility  in 
allocating  workloads  for  OFF  modification. 

#3  -  Pursue  Public-Private  Partnerships  for  Development  and  Maintenance 

The  government  should  maintain  a  depot  maintenance  capability  to  build  the 
skills  and  knowledge  required  to  maintain  technical  oversight  of  private  contractors, 
increase  competition  for  work,  add  workforce  during  time  of  need,  and  prepare  for  the 
transition  from  partnerships  to  full  government  sustainment  when  appropriate.  Partnering 
would  remain  a  good  option  for  both  OFP  maintenance/sustainment  and  development. 
Partnering  agreements  would  no  longer  serve  as  a  means  to  satisfy  core  workload  levels 
inflated  by  OFP  development  work  misclassified  as  maintenance. 

Instead,  a  typical  OFP  logistics  plan  would  include  an  incremental  transition  from 
primarily  private  work  to  primarily  government  work  over  the  life  of  a  system.  Private 
industry  would  perform  the  initial  development  prior  to  IOC  and  maintain  the  OFP  for 
several  years  following  IOC.  At  this  point  the  government  would  partner  with  industry  to 
maintain  those  OFP  releases  classified  as  maintenance,  gaining  familiarity  and  expertise 
in  that  OFP  family.  The  contractor  would  focus  on  development  of  the  next  major  release 
(not  counted  toward  core  labor  hours).  Over  time  the  contractor’s  interest  might  move 
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toward  new  aircraft  systems,  and  the  government  would  pick  up  the  majority  of  work  late 
in  the  aircraft’s  life  when  OFF  development  is  likely  to  decrease. 

This  arrangement  would  allow  the  government  to  gain  technical  understanding  of 
and  skill  with  an  OFF  early  in  the  life  cycle  in  preparation  for  later  years  when  a 
particular  OFF  would  move  into  a  sustainment  period.  Government  involvement  through 
partnering  would  also  allow  the  government  to  maintain  credible  technical  oversight  of 
progress  on  the  contractor’s  portion  of  the  work.  The  life  cycle  plan  for  OFF 
development  and  sustainment  could  then  be  tailored  for  each  aircraft  program.  Some 
might  be  heavily  developmental  for  a  long  period  and  the  government’s  role  would  be 
smaller  for  a  longer  period  of  time.  Other  programs  may  transition  to  primarily 
government  work  earlier.  This  increase  in  flexibility  would  be  an  improvement  over  the 
current  inflexible  approach  whereby  all  OFF  modification  is  considered  software 
maintenance  and  work  allocation  is  subject  to  Title  10. 


OFP  Work  Allocation  Over  the  Lifecycle  (Proposed) 
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Figure  30.  OFP  work  allocation  over  the  lifecycle 
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In  summary,  the  work  on  a  single  OFP  release  would  generally  move  from  left  to 
right  in  Figure  30.  As  the  operational  OFP  release  moves  to  the  right,  the  next  release 
begins  at  left  and  slowly  moves  right  over  time,  as  the  government’s  proportion  of  the 
partnership  work  increases.  This  is  intended  as  a  notional  plan  only.  OFPs  of  specific 
aircraft  might  vary  from  this  plan.  A  partnership  may  exist  until  the  system  is  disposed, 
or  OFP  work  might  be  all  public  earlier  than  depicted.  After  establishing  clear 
definitions,  this  general  arrangement  could  be  implemented  with  minimal  changes  to 
existing  policy. 

#4  -  Add  a  Risk  Assessment  to  Title  10 

The  motivation  for  Title  lO’s  requirement  to  maintain  an  organic  depot 
maintenance  and  repair  capability  is  rooted  in  a  Cold  War  prolonged  hardware-centric 
conflict  that  is  no  longer  applicable  today  because  the  risk  of  private  sustainment  is 
decreased.  Therefore,  this  research  recommends  that  Title  10  be  amended  to  allow  a  risk 
assessment  prior  to  entering  the  core  capability  determination  process.  For  example,  if  an 
OFP  release  were  determined  to  be  maintenance  and  therefore  subject  to  Title  10  core 
requirements,  a  risk  assessment  would  be  performed  before  work  allocation.  If  the  risk  to 
the  government  were  assessed  as  low,  the  work  might  be  given  to  the  private  sector  even 
though  the  workload  would  be  core.  If  the  OFP  work  were  classified  as  development  and 
therefore  not  a  core  capability,  this  risk  analysis  would  not  be  applicable.  But  for  any 
system  workload  that  is  designated  as  supporting  a  core  capability,  the  risk  analysis  may 
reveal  low  risk  situations  where  other  decision  factors  such  as  cost-effectiveness  should 
have  higher  priority. 
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This  recommendation  is  depicted  by  way  of  a  new  functional  model  in  Figure  31. 
Added  items  are  shown  in  red  for  comparison  with  the  “as-is”  architecture  in  (Figure  15). 
If  the  risk  analysis  assesses  high  risk  of  reliance  on  the  private  sector,  then  the  work 
hours  continue  into  the  core  and  50/50  calculations.  If  the  risk  is  assessed  as  low,  the 
option  exits  to  bypass  core  calculations  and  enter  at  50/50  calculations. 
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Figure  31.  SORAP  decision  process  (to-be) 
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#5  -  Remove  the  Four  Year  Post-IOC  Deadline  from  Title  10 


Title  10  Section  2464  requires  establishing  an  organic  maintenance  capability 
within  four  years  after  IOC  for  a  new  system.  This  timeline  is  arbitrary  and  best  applied 
to  hardware  which  reaches  some  measure  of  stability  after  IOC.  OTPs  often  do  not  reach 
a  stable  state  as  new  releases  are  developed  to  support  significant  new  requirements  and 
capabilities.  This  research  recommends  that  this  requirement  in  Title  10  be  removed. 
DoD  policy  should  require  program  managers,  in  conjunction  with  AFMC  headquarters, 
to  plan  depot  workload  allocations  for  the  entire  lifecycle  in  a  manner  that  suits  the 
program  under  consideration.  An  OFP’s  lifecycle  logistics  plan  should  be  flexible  - 
designed  for  smooth  transition  from  private  development  to  a  sustainment  partnership 
between  government  and  private  sectors,  and  then  to  wholly  government  sustainment  if 
and  when  appropriate. 

Suggested  Future  Research 

The  models  proposed  by  this  research  could  be  expanded  and  improved  for 
greater  application  and  accuracy.  Expanding  the  research  beyond  combat  Air  Force 
programs  might  reveal  more  ways  to  characterize  an  OFP.  The  models  should  be  further 
validated  by  applying  them  to  a  greater  number  of  historical  OFPs  in  multiple  types  of 
aircraft  systems. 

Second,  tools  should  be  developed  to  aid  in  the  proposed  risk  assessment.  Such  a 
model  might  include  a  measure  of  the  health  of  private  industry,  the  characteristics  of  the 
warfare  environment  for  the  system  in  question,  and  characteristics  of  the  system  itself 
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The  tool’s  output  would  be  a  predietion  of  risk  to  the  government  of  relying  on  the 
private  sector  for  depot-level  sustainment  of  the  system. 

Third,  research  should  be  conducted  into  funding  practices  by  program  offices.  If 
common  definitions  are  proposed  and  OFF  modification  work  is  methodically 
categorized  as  maintenance  or  development,  funding  appropriate  to  workload 
classification  should  be  planned,  programmed,  and  budgeted.  Currently,  the  program 
offices  interviewed  are  using  funding  that  is  available  or  that  subjectively  matches  the 
work  at  hand.  Some  offices  are  using  development  money,  while  others  tap  operations 
and  maintenance  funds  for  similar  work.  It  would  be  ideal  for  the  classification  of  the 
work,  the  characteristics  of  the  work,  and  the  funding  source  to  all  match  each  other. 
Development  work  should  be  categorized  as  development  and  funded  with  development 
funds. 
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Appendix  A:  Definitions 


Table  6.  Various  Definitions  Relating  to  the  Sustainment,  Maintenance,  and  Modification  of  Software 


Sustainment 


Maintenance  Software  Specific  Terms  Related  terms 


Title  10  Sec  2464 


None 


Definition  of  Depot 
Level  Maintenance 
and  Repair 

1996  SW  added  to 
law  (2466) 


Material  maintenance  or  repair 
requiring  the  overhaul, 
upgrading,  or  rebuilding  of  parts, 
assemblies,  or  subassemblies, 
and  the  testing  and  reclamation 
of  equipment  as  necessary, 
regardless  of  the  source  of  funds 
for  the  maintenance  or  repair  or 
the  location  at  which  the 
maintenance  or  repair  is 
performed.  The  term  includes  (1) 
all  aspects  of  software 
maintenance  as  depot-level 
maintenance  and  repair,  and  (2) 
interim  contractor  support  or 
contractor  logistics  support  (or 
any  similar  contractor  support), 
to  the  extent  that  such  support  is 
for  the  performance  of  services 
described  in  the  preceding 
sentence. 


None 


(b)  Exceptions.  -  (1)  The  term 
does  not  include  the 
procurement  of  major 
modifications  or  upgrades  of 
weapon  systems  that  are 
designed  to  improve  program 
performance. 


None 
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Sustainment 

Maintenance 

DoD  5000.01 

None 

None 

The  Defense 
Acquisition  System 

DoD  5000.02 

Life-cycle  sustainment  planning 

None 

Operation  of  the 
Defense  Acquisition 
System 

and  execution  seamlessly  span  a 
system's  entire  life  cycle,  from 
Materiel  Solution  Analysis  to 
disposal.  It  translates  force 
provider  capability  and 
performance  requirements  into 
tailored  product  support  to 
achieve  specified  and  evolving 
life-cycle  product  support 
availability,  reliability,  and 
affordability  parameters. 

DOD7000.14-RV2A 

Depot  and  field  level 

Depot  and  field  level 

Budget  Formulation 
and  Presentation 

maintenance  is  the  routine, 
recurring  effort  conducted  to 
sustain  the  operational 
availability  of  an  end  item. 

maintenance  includes 
refurbishment  and  overhaul  of 
end  items,  removal  and 
replacement  of  secondary  items 
and  components,  as  well  as 
repair  and  remanufacturing  of 
reparable  components.  The 
maintenance  effort  may  be 
performed  by  government 
agency  or  by  a  contractor. 

Maintenance,  repair,  overhaul, 
and  rework  of  equipment  are 
funded  in  the  operation  and 
maintenance  appropriations. 
However,  maintenance  of 
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Software  Specific  Terms  Related  terms 


None 


None 


None 


None 


d.  Continuous  technology 
refreshnnent  is  the  intentional, 
incrennental  insertion  of  newer 
technology  to  innprove  reliability, 
innprove  nnaintainability,  reduce 
cost,  and/or  add  nninor 
perfornnance  enhancennent, 
typically  in  conjunction  with 
depot  or  field  level  nnaintenance. 
The  insertion  of  such  technology 
into  end  itenns  as  part  of 
nnaintenance  is  funded  by  the 
operation  and  nnaintenance 
appropriations.  However, 
technology  refreshnnent  that 
significantly  changes  the 
perfornnance  envelope  of  the 


Sustainment 

Maintenance 

equipnnent  used  exclusively  for 
research,  developnnent,  test,  and 
evaluation  efforts  will  be  funded 
by  the  RDT&E  appropriations. 

DODD  4151.18 

Maintenance  of 
Military  Materiel 

None 

Maintenance  tasks  restore  safety 
and  reliability  to  their  inherent 
levels  when  deterioration  has 

occurred. 

DoD  4151.18-H 

Depot  Maintenance 
Capacity  and 
Utilization 

Measurement 

Handbook 

Core-sustaining  workload 
ensures  technical  connpetence  in 
peacetinne  while  preserving  the 
surge  capacity  and  reconstitution 
capabilities  necessary  to  fully 
support  the  strategic  and 
contingency  plans  prepared  by 
the  Chairnnan  of  the  Joint  Chiefs 

of  Staff. 

The  processes  of  materiel 
maintenance  or  repair  involving 
the  overhaul,  upgrading, 
rebuilding,  testing,  inspection, 
and  reclamation  (as  necessary)  of 
weapons  systems,  equipment 
end  items,  parts,  components, 
assemblies,  and  subassemblies. 
Depot  maintenance  also  includes 
all  aspects  of  software 
maintenance,  the  installation  of 
parts  or  components  for 
modifications,  and  technical 
assistance  to  intermediate 
maintenance  organizations, 
operational  units  and  other 
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Software  Specific  Terms 


None 


Related  terms 


end  itenn  is  considered  a 
nnodification  and,  therefore,  an 
investnnent  (See  section  on 
''Product  Innprovennent"  010212 
C.  7.).  This  definition  applies 
equally  to  technology  insertion 
by  connnnercial  firnns  as  part  of 
contractor  logistics  support, 
prinne  vendor,  and  sinnilar 
arrangennents  and  to  technology 
insertion  that  is  perfornned 
internally  by  the  Departnnent. 

None 


None 


None 


Sustainment 


Maintenance 


Software  Specific  Terms 


Related  terms 


Depot  Maintenance 
Core  Capabilities 
Determination 
Process 


DODI  4151.21 


Public-Private 
Partnerships  for 
Depot-Level 
Maintenance 


activities.  Depot  maintenance  is 
typically  accomplished  in  fixed 
shops,  shipyards  and  other 
shore-based  facilities,  or  by  field 
teams,  using  more  extensive 
shop  facilities,  equipment,  and 
personnel  of  higher  technical  skill 
than  are  available  at  lower 
echelons  of  maintenance. 


The  processes  of  materiel 
maintenance  or  repair  involving 
the  overhaul,  upgrading, 
rebuilding,  testing,  inspection, 
and  reclamation  (as  necessary)  of 
weapons  systems,  equipment 
end  items,  parts,  components, 
assemblies,  and  subassemblies. 
Depot  maintenance  also  includes 
all  aspects  of  software 
maintenance; 


The  processes  of  materiel 
maintenance  or  repair  involving 
the  overhaul,  upgrading, 
rebuilding,  testing,  inspection, 
and  reclamation  (as  necessary)  of 
weapon  systems,  equipment  end 
items,  parts,  components, 
assemblies,  and  subassemblies. 
Depot-level  maintenance  also 
includes  all  aspects  of  software 
maintenance,  the  installation  of 
parts  or  components  for 


Software.  A  set  of  computer 
programs,  procedures,  and 
associated  documentation 
concerned  with  the  operation  of 
a  data-processing  system  (e.g., 
compilers,  library  routines, 
manuals,  and  circuit  diagrams). 
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Sustainment 


Maintenance 


Software  Specific  Terms 


Related  terms 


modifications,  and  technical 
assistance  to  intermediate 
maintenance  organizations, 
operational  units,  and  other 
activities. 

Depot-level  maintenance 
activity.  A  specific  DoD-owned 
and  DoD-operated  facility 
established,  equipped,  and 
staffed  to  carry  out  depot-level 
maintenance.  DoD  depot-level 
maintenance  activities 
accomplish  a  wide  range  of 
depot-level  maintenance 
processes  including  overhaul, 
conversion,  activation, 
inactivation,  renovation, 
analytical  rework,  repair, 
modifications  and  upgrades, 
inspection,  manufacturing, 
reclamation,  storage,  software 
support,  calibration,  and 
technical  assistance. 

DODI  4151.22  None  Maintenance  can  be  performed  None 

using  a  wide  variety  of 

Condition  Based  approaches.  Two  main  categories 

Maintenance  Plus  of  maintenance  -  reactive  and 

for  Materiel  proactive  -  are  provided  to 

Maintenance  describe  the  range  of  options 

available. 

_ Reactive  maintenance  (i.e., _ 


None 
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corrective  maintenance). 
Performed  for  items  that  are 
selected  to  run  to  failure  or 
those  items  that  fail  in  an 
unplanned  or  unscheduled 
manner.  Run  to  failure  is  often 
the  planned  maintenance 
strategy  for  items  that  have  little 
readiness  or  safety  impact. 

Proactive  maintenance.  This 
type  of  maintenance  can  be 
considered  as  either  preventive 
or  predictive  in  nature,  and  the 
maintenance  performed  includes 
inspection,  assessment,  test, 
diagnostics,  prognostics, 
servicing,  and  scheduled 
replacement/overhaul. 

JP  1-02  Sustainment  —  The  provision  of  Maintenance  (materiel)  —  1.  All 

logistics  and  personnel  services  action  taken  to  retain  materiel  in 
Department  of  required  to  maintain  and  prolong  a  serviceable  condition  or  to 

Defense  Dictionary  operations  until  successful  restore  it  to  serviceability.  It 

of  Military  and  mission  accomplishment  includes  inspection,  testing. 

Associated  Terms  servicing,  and  classification  as  to 

serviceability,  repair,  rebuilding, 
and  reclamation. 

2.  All  supply  and  repair  action 
taken  to  keep  a  force  in 
condition  to  carry  out  its  mission. 

3.  The  routine  recurring  work 

_ required  to  keep  a  facility  (plant. 
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None 


None 


Sustainment 


Maintenance 
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Related  terms 


JP3-0 

Joint  Operations 

JP4-0 


building,  structure,  ground 
facility,  utility  systenn,  or  other 
real  property)  in  such  condition 
that  it  nnay  be  continuously  used 
at  its  original  or  designed 
capacity  and  efficiency  for  its 
intended  purpose. 

materiel  —  All  items  (including 
ships,  tanks,  self-propelled 
weapons,  aircraft,  etc.,  and 
related  spares,  repair  parts,  and 
support  equipment,  but 
excluding  real  property, 
installations,  and  utilities) 
necessary  to  equip,  operate, 
maintain,  and  support  military 
activities  without  distinction  as 
to  its  application  for 
administrative  or  combat 
purposes.  See  also  equipment; 


The  sustainment  function 

encompasses  a  number  of  tasks 
including: 

None 

None 

None 

(2)  Providing  for  maintenance  of 
equipment. 

Sustainment  is  the  provision  of 

Maintenance  is  accomplished 

None 

None 

logistics  and  personnel  services 

across  DoD  at  two  levels:  depot 

necessary  to  maintain  and 

level  (sustainment)  and  field 

prolong  operations  until 

level  (intermediate  and 

successful  mission  completion. 

organizational). 

Joint  Logistics 


Sustainment 

Maintenance 

(1)  Depot  Maintenance 
Operations.  The  purpose  of 
depot  maintenance  is  to  repair, 
modify,  rebuild,  and  overhaul 
both  entire  systems  and 
components. 

(2)  Field  Maintenance 

Operations.  The  purpose  of  field 
level  maintenance  is  to  rapidly 
return  systems  to  users  in  a 
ready  status. 

AFPD  63-1 

Acquisition  and 
Sustainment  Life 
Cycle  Management 

Sustainment— continuing 
materiel  support  which  consists 
of  the  planning,  programming, 
and  execution  of  a  logistics 
support  strategy  for  a  system, 
subsystem,  or  major  end-item  to 
maintain  operational  capabilities 
from  system  fielding  through 
disposal. 

None 

AFI  63-101 

Acquisition  and 
Sustainment  Life 
Cycle  Management 

Sustainment— Continuing 
materiel  support  which  consists 
of  the  planning,  programming, 
and  execution  of  a  logistics 
support  strategy  for  a  system, 
subsystem,  or  major  end  item  to 
maintain  operational  capabilities 
from  system  fielding  through 
disposal. 

None 
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None 


Modification— a  modification  is 
defined  as  a  change  to  the  form, 
fit,  function,  or  interface  (F3I)  of 
an  in-service,  configuration- 
managed  AF  asset. 


Software  Maintenance— Those 
activities  necessary  to  correct 
errors  in  the  software;  add 
incremental  capability 
improvements  (or  delete 
unneeded  features)  through 
software  changes;  and  adapt 
software  to  retain  compatibility 
with  hardware  or  with  other 
systems  with  which  the  software 
interfaces.  Software 
maintenance  comprises  software 


Modification— For  the  purposes 
of  this  instruction,  a  modification 
is  defined  as  a  change  to  the 
form,  fit,  function,  or  interface 
(F3I)  of  an  in-service, 
configuration-managed  AF  asset. 
Modifications  are  primarily 
defined  by  their  purpose.  A 
capability  modification  alters  the 
F3I  of  an  asset  in  a  manner  that 
requires  a  change  to  the  existing 
system,  performance,  or 


Sustainment 


Maintenance 


AFI  63-107 
(replaced  by 


Sustainment  is  the  planning,  Maintenance:  the  orderly 

programming  and  executing  of  a  arrangement  of  all  maintenance 
support  strategy  for  a  system,  support,  including  support 
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maintenance  performed  on 
military  materiel  (e.g.  weapon 
systems  and  their  components, 
space  control  systems  and  their 
components,  automated  test 
equipment  and  test  package 
sets,  and  systems  integration 
laboratories). 


Related  terms 


technical  specification  of  the 
asset.  Such  modifications  are 
generally  accomplished  to  add  a 
new  capability  or  function  to  a 
system  or  component,  or  to 
enhance  the  existing  technical 
performance  or  operational 
effectiveness  of  the  asset. 

A  sustainment  modification 
alters  the  F3I  of  an  asset  in  a 
manner  that  does  not  change  the 
existing  system,  performance,  or 
technical  specification  of  the 
asset.  Such  modifications  are 
generally  accomplished  to 
correct  product  quality 
deficiencies,  or  to  bring  the  asset 
in  compliance  with,  or  to 
maintain  the  established 
technical  or  performance 
specification(s)  associated  with 
the  asset.  Sustainment 
modifications  may  also  include 
efforts  that  are  accomplished  for 
the  primary  purpose  of 
improving  the  reliability, 
availability,  maintainability,  or 
supportability  of  an  asset,  or  to 
reduce  its  ownership  costs. 


Software  Maintenance— Those 
activities  necessary  to:  1)  correct 


Acquisition  is  the 
conceptualization,  initiation, 
design,  development,  test. 


AFI  63-101) 


Sustainment 


Maintenance 


subsystem  or  major  end  item  to 
maintain  operational  capabilities 
from  system  fielding  through 
disposal. 


equipment  and  facilities,  to  keep 
systems  and  equipment  ready  to 
perform  assigned  missions.  This 
includes  all  levels  of  maintenance 
and  implementation  of  those 
levels  (includes  any  partnering, 
organic  and  contract  support). 


AFI  65-601V1 


Budget  Guidance 
and  Procedures 


Depot  Maintenance— Materiel 
maintenance  or  repair 
performed  by  contractor  or 
organic  depots  requiring  the 
overhaul  or  rebuilding  of  parts, 
assemblies,  or  subassemblies, 
and  the  testing  and  reclamation 
of  equipment  as  necessary.  The 
term  includes  all  aspects  of 
software  maintenance  as 
classified  by  the  DoD  as  of  1  July 
1995  as  depot  level  maintenance 
and  repair. 


Maintenance— The  routine, 
recurring  work  necessary  to  keep 
an  end  item  of  equipment  or 
configuration  item  at  its  current 
or  intended  operation  capability 
or  designed  performance. 
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errors  in  the  software; 

2)  add  incremental  capability 
improvements  (or  delete 
unneeded  features)  through 
software  changes;  and 

3)  adapt  software  to  retain 
compatibility  with  hardware  or 
with  other  systems  with  which 
the  software  interfaces.  Software 
maintenance  comprises  software 
maintenance  performed  on 
military  materiel  (e.g.  weapon 
systems  and  their  components, 
space  control  systems  and  their 
components,  automated  test 
equipment  and  test  package 
sets,  and  systems  integration 
laboratories). 


Computers:  Software 
Maintenance— Efforts  associated 
with  eliminating  faults  in 
software  to  ensure  that  an 
information  system  (IS)  or 
application  is  in  a  satisfactory 
working  condition. 

Computers:  Weapon  Support 
Systems  Embedded 
Computers—  Embedded 
computers  are  those  integral  to 


Related  terms 


contracting,  production  and 
deployment  of  a  directed  and 
funded  effort  that  provides  a 
new,  improved  or  continued 
materiel,  weapon,  information 
system  or  service  capability  in 
response  to  an  approved  need. 


Modification— An  alteration  to  a 
configuration  item  applicable  to 
aircraft,  missiles,  support 
equipment,  ground  stations 
software  (imbedded),  trainers, 
etc.  As  a  minimum,  the  alteration 
changes  the  form,  fit,  function  or 
interface  of  the  item. 


Computers:  Software  Changes— 

Efforts  associated  with  revision 
or  alteration  of  an  existing  IS  or 
application  to  support  the 
changes  in  design  specification 
required  by  the  functional 
manager  and  higher  authority.  It 
encompasses  changing 
programs,  reformatting,  and 
documentation  thereof. 

Software  conversions  are  funded 
as  software  changes. 


Sustainment 


Maintenance 


T.O.  00-25-4 


None 


Depot  Maintenance 
of  Aerospace 
Vehicles  and 
Training  Equipment 


The  level  of  maintenance 
consisting  of  those  on  and  off- 
equipment  tasks  performed 
using  highly  specialized  skills, 
sophisticated  shop  equipment, 
or  special  facilities  of  an  ALC, 
centralized  repair  activity, 
contractor  facility,  or,  by  field 
teams  at  an  operating  location. 


GSAM  Handbook 


Guidelines  for 
Successful 
Acquisition  and 
Management  of 
Software  Intensive 


Sustainment  is  often  thought  of 
in  the  context  of  fixing  bugs,  but 
it  can  be  of  four  different  types, 
depending  on  the  reason  or 
need.  While  a  sustainment  effort 
may  be  precipitated  by  a  single 
type  of  sustainment  need,  most 


None 
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weapon  systems,  intelligence 
systems,  command  and  control 
systems,  communication 
systems,  and  other  support 
systems  and  facilities,  such  as 
automatic  test  equipment, 
simulators  and  other  training 
devices,  etc.  This  includes 
computer  resources  acquired 
and  managed  per  acquisition 
instructions  (API  63-xxx  series 
and  DODI  5000.2).  These 
computers  are  integral  to  and  in 
direct  support  of  a  major  system 
or  a  less-than-major  system. 
None 


Maintenance  Phase  includes 
fixing  errors  and  modifying  or 
upgrading  the  software  to 
provide  additional  functionality, 
such  as  enabling  the  software  to 
work  with  new  computing 
platforms 


Related  terms 


Development  Engineering- 

Development  engineering 
includes  the  engineering  effort 
required  to  define,  develop, 
optimize,  design,  integrate,  test, 
evaluate,  and  verify  a  new 
weapon  system,  equipment, 
modification,  or  other  product 
prior  to  production.  Also 
applicable  to  extensive  redesign 
and  requalification  of  an  existing 
item  or  system  (including 
embedded  ADP  systems,  both 
hardware  and  software). 

Modification  -  A  physical 
alteration  of  equipment  that 
changes  its  capabilities  or 
characteristics,  i.e.,  form,  fit  or 
function. 


None 


Sustainment 


Maintenance 
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Related  terms 


Systems  efforts  include  two  or  more 

sustainment  types.  The  four 
types  are  summarized  here.  [2] 

1.  Corrective  Sustainment  - 

diagnosis  and  correction  of 
program  errors  after  its  release. 

2.  Perfective  Sustainment  -  the 

addition  of  new  capabilities  and 
functionality  to  existing  software. 

3.  Adaptive  Sustainment  - 

modification  of  software  to 
interface  with  a  changing 
environment. 

4.  Preventive  Sustainment  - 

modification  of  software  to 
improve  future  maintainability  or 
reliability. 

Corrective  sustainment  requires 
examination  of  the  existing 
program  code  to  determine  the 
cause  of  the  error,  analysis  to 
determine  the  best  way  to 
correct  the  error  without 
introducing  new  errors,  and 
regression  testing  to  validate 
that  the  original  error  has  been 
eliminated  without  introducing 
new  errors.  Perfective  and 
Adaptive  sustainment  usually 
involve  a  complete  development 
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effort  with  requirements,  design, 
coding,  and  integration  and  test 
phases.  Preventive  sustainment 
is  performed  by  reverse 
engineering  the  existing  software 
and  re-engineering 
(redeveloping)  it. 

IEEE  610.12-1990 

Standard  Glossary 
of  Software 
Engineering  Terms 

None 

Maintenance.  (1)  The  process  of 
modifying  a  software  system  or 
component  after  delivery  to 
correct  faults,  improve 
performance  or  other  attributes, 
or  adapt  to  a  changed 
environment. 

Syn:  software  maintenance.  See 
also:  adaptive  maintenance; 
corrective  maintenance; 
perfective  maintenance. 

(2)  The  process  of  retaining  a 
hardware  system  or  component 
in,  or  restoring  it  to,  a  state  in 
which  it  can  perform  its  required 
functions.  See  also:  preventive 
maintenance 
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Software  maintenance.  See: 
maintenance  (1). 


Adaptive  Maintenance.  Software 
maintenance  performed  to  make 
a  Computer  program  usable  in  a 
changed  environment. 

Corrective  Maintenance. 

Maintenance  performed  to 
correct  faults  in  hardware  or 
software. 

Perfective  Maintenance. 

Software  maintenance 
performed  to  improve  the 
performance,  maintainability,  or 
other  attributes  of  a  computer 
program. 


Related  terms 


Software  development  cycle. 

The  period  of  time  that  begins 
with  the  decision  to  develop  a 
software  Product  and  ends  when 
the  software  is  delivered.  This 
cycle  typically  includes  a 
requirements  phase,  design 
phase,  implementation  phase, 
test  phase,  and  sometimes, 
installation  and  checkout  phase. 

Contrast  with:  software  life 
cycle. 

Notes:  (1)  The  phases  listed 
above  may  overlap  or  be 
performed  iteratively,  depending 
upon  the  software  development 
approach  used. 

(2)  This  term  is  sometimes  used 
to  mean  a  longer  period  of  time, 
either  the  period  that  ends  when 
the  software  is  no  longer  being 
enhanced  by  the  developer,  or 
the  entire  software  life  cycle. 


Sustainment 


Maintenance 


None  None 

Standard  for 

Software 

Maintenance 


IEEE  1219-1992 
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Related  terms 


Software  life  cycle.  The  period  of 
time  that  begins  when  a 
software  product  is  conceived 
and  ends  when  the  software  is 
no  longer  available  for  use.  The 
software  life  cycle  typically 
includes  a  concept  phase, 
requirements  phase,  design 
phase,  implementation  phase, 
test  phase,  installation  and 
checkout  phase,  operation  and 
maintenance  phase,  and, 
sometimes,  retirement  phase. 
Note:  These  phases  may  overlap 
or  be  performed  iteratively. 
Contrast  with:  software 
development  cycle. 

Software  maintenance: 

Modification  of  a  software 
product  after  delivery  to  correct 
faults,  to  improve  performance 
or  other  attributes,  or  to  adapt 
the  product  to  a  modified 
environment. 

Adaptive  maintenance: 

Modification  of  a  software 
product  performed  after  delivery 
to  keep  a  computer  program 
usable  in  a  changed  or  changing 
environment. 

Corrective  maintenance: 

None 

Sustainment 


Maintenance 


NAVAIR  Software  Software  Support  Activity  (SSA)  - 
Logistics  Primer  A  Software  Support  Activity 
assumes  the  role  of  providing 
post-deployment  life  cycle 
support  for  modifications  or 
upgrades  made  to  a  system's 
software  following  the  system's 
initial  fielding.  System 
modifications  and  upgrades 
include  multi-system  changes, 
block  changes,  preplanned 
product  improvements,  repair  of 
deficiencies  reported  by  the  user, 
and  other  types  of  system 
change  packages.  The  SSA 
organization  typically  compiles 
these  needed  updates  into 
formal  software  releases  to  avoid 
disrupting  the  fielded  system. 
Software  development  activities 
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Reactive  modification  of  a 
software  product  performed 
after  delivery  to  correct 
discovered  faults. 

Emergency  maintenance: 

Unscheduled  corrective 
maintenance  performed  to  keep 
a  system  operational. 

Perfective  maintenance: 

Modification  of  a  software 
product  after  delivery  to  improve 
performance  or  maintainability. 

Software  Maintenance  (a.k.a. 
software  sustainment)  - 
Modification  of  a  software 
product  after  delivery  to  correct 
faults,  to  improve  performance 
or  other  attributes,  or  to  adapt 
the  product  to  a  modified 
environment.  Software 
maintenance  typically  consists  of 
the  following  activities: 

Corrective  maintenance: 

reactive  modification  to  correct 
discovered  problems 

Adaptive  maintenance: 

modification  to  keep  software 
usable  in  a  changed  environment 
•  Perfective:  modification 
to  improve  performance  or 


Sustainment 


Maintenance 


performed  by  a  SSA  in  providing 
life  cycle  support  are  the  same  as 
those  carried  out  during  the 
development  effort  that  led  to 
the  first  fielding.  They  are 
tailored,  as  appropriate,  to 
reflect  the  effort  required  to 
implement  each  change  package, 
update  pertinent 
documentation,  verify  the 
changes,  and  distribute  the 
changes  to  users. 

USAF  Weapon 
Svstems  Software 
Management 
Guidebook 
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maintainability 
•  Preventive: 
modification  to  detect  and 
correct  latent  faults 


Software  repair  involves 
returning  a  deficient  design  to 
specification  or  incorporating 
new  requirements  (originated  or 
derived).  The  processes  required 
to  repair  or  maintain  software 
are  very  similar  to  those  used  to 
develop  it.  Software  repair 
requires  requirement  trades, 
design  reiteration,  interface 
control,  prototyping,  integration, 
testing,  verification,  fielding 
planning,  and  metrics. 


Appendix  B:  Text  of  United  States  Code,  Title  10 

(those  Sections  relevant  to  the  requirement  for  organic  core  logistics) 


Section  2464 


(link:  return  to  document) 


Core  logistics  capabilities 


(a)  Necessity  for  Core  Logistics  Capabilities. — 

(1)  It  is  essential  for  the  national  defense  that  the  Department  of  Defense  maintain 
a  core  logistics  capability  that  is  Government-owned  and  Government-operated 
(including  Government  personnel  and  Government-owned  and  Government- 
operated  equipment  and  facilities)  to  ensure  a  ready  and  controlled  source  of 
technical  competence  and  resources  necessary  to  ensure  effective  and  timely 
response  to  a  mobilization,  national  defense  contingency  situations,  and  other 
emergency  requirements. 

(2)  The  Secretary  of  Defense  shall  identify  the  core  logistics  capabilities 
described  in  paragraph  (1)  and  the  workload  required  to  maintain  those 
capabilities. 

(3)  The  core  logistics  capabilities  identified  under  paragraphs  (1)  and  (2)  shall 
include  those  capabilities  that  are  necessary  to  maintain  and  repair  the  weapon 
systems  and  other  military  equipment  (including  mission-essential  weapon 
systems  or  materiel  not  later  than  four  years  after  achieving  initial  operational 
capability,  but  excluding  systems  and  equipment  under  special  access  programs, 
nuclear  aircraft  carriers,  and  commercial  items  described  in  paragraph  (5))  that  are 
identified  by  the  Secretary,  in  consultation  with  the  Chairman  of  the  Joint  Chiefs 
of  Staff,  as  necessary  to  enable  the  armed  forces  to  fulfill  the  strategic  and 
contingency  plans  prepared  by  the  Chairman  of  the  Joint  Chiefs  of  Staff  under 
section  153  (a)  of  this  title. 

(4)  The  Secretary  of  Defense  shall  require  the  performance  of  core  logistics 
workloads  necessary  to  maintain  the  core  logistics  capabilities  identified  under 
paragraphs  (1),  (2),  and  (3)  at  Government-owned,  Government-operated 
facilities  of  the  Department  of  Defense  (including  Government-owned, 
Government-operated  facilities  of  a  military  department)  and  shall  assign  such 
facilities  sufficient  workload  to  ensure  cost  efficiency  and  technical  competence 
in  peacetime  while  preserving  the  surge  capacity  and  reconstitution  capabilities 
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necessary  to  support  fully  the  strategic  and  contingency  plans  referred  to  in 
paragraph  (3). 

(5)  The  commercial  items  covered  by  paragraph  (3)  are  commercial  items  that 
have  been  sold  or  leased  in  substantial  quantities  to  the  general  public  and  are 
purchased  without  modification  in  the  same  form  that  they  are  sold  in  the 
commercial  marketplace,  or  with  minor  modifications  to  meet  Federal 
Government  requirements. 

(b)  Limitation  on  Contracting. — 

(1)  Except  as  provided  in  paragraph  (2),  performance  of  workload  needed  to 
maintain  a  logistics  capability  identified  by  the  Secretary  under  subsection  (a)(2) 
may  not  be  contracted  for  performance  by  non-Govemment  personnel  under  the 
procedures  and  requirements  of  Office  of  Management  and  Budget  Circular  A-76 
or  any  successor  administrative  regulation  or  policy  (hereinafter  in  this  section 
referred  to  as  0MB  Circular  A-76). 

(2)  The  Secretary  of  Defense  may  waive  paragraph  (1)  in  the  case  of  any  such 
logistics  capability  and  provide  that  performance  of  the  workload  needed  to 
maintain  that  capability  shall  be  considered  for  conversion  to  contractor 
performance  in  accordance  with  0MB  Circular  A-76.  Any  such  waiver  shall  be 
made  under  regulations  prescribed  by  the  Secretary  and  shall  be  based  on  a 
determination  by  the  Secretary  that  Government  performance  of  the  workload  is 
no  longer  required  for  national  defense  reasons.  Such  regulations  shall  include 
criteria  for  determining  whether  Government  performance  of  any  such  workload 
is  no  longer  required  for  national  defense  reasons. 

(3) 

(A)  A  waiver  under  paragraph  (2)  may  not  take  effect  until  the  expiration 
of  the  first  period  of  30  days  of  continuous  session  of  Congress  that  begins 
on  or  after  the  date  on  which  the  Secretary  submits  a  report  on  the  waiver 
to  the  Committee  on  Armed  Services  and  the  Committee  on 
Appropriations  of  the  Senate  and  the  Committee  on  Armed  Services  and 
the  Committee  on  Appropriations  of  the  House  of  Representatives. 

(B)  For  the  purposes  of  subparagraph  (A) — 

(i)  continuity  of  session  is  broken  only  by  an  adjournment  of 
Congress  sine  die;  and 

(ii)  the  days  on  which  either  House  is  not  in  session  because  of  an 
adjournment  of  more  than  three  days  to  a  day  certain  are  excluded 
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in  the  computation  of  any  period  of  time  in  which  Congress  is  in 
continuous  session. 


(c)  Notification  of  Determinations  Regarding  Certain  Commercial  Items. — 

The  first  time  that  a  weapon  system  or  other  item  of  military  equipment  described  in 
subsection  (a)(3)  is  determined  to  be  a  commercial  item  for  the  purposes  of  the  exception 
contained  in  that  subsection,  the  Secretary  of  Defense  shall  submit  to  Congress  a 
notification  of  the  determination,  together  with  the  justification  for  the  determination. 

The  justification  for  the  determination  shall  include,  at  a  minimum,  the  following: 

(1)  The  estimated  percentage  of  commonality  of  parts  of  the  version  of  the  item 
that  is  sold  or  leased  in  the  commercial  marketplace  and  the  Government’s 
version  of  the  item. 

(2)  The  value  of  any  unique  support  and  test  equipment  and  tools  that  are 
necessary  to  support  the  military  requirements  if  the  item  were  maintained  by  the 
Government. 

(3)  A  comparison  of  the  estimated  life  cycle  logistics  support  costs  that  would  be 
incurred  by  the  Government  if  the  item  were  maintained  by  the  private  sector  with 
the  estimated  life  cycle  logistics  support  costs  that  would  be  incurred  by  the 
Government  if  the  item  were  maintained  by  the  Government. 
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Section  2460 


(link:  return  to  document) 

Definition  of  depot-level  maintenance  and  repair 

(a)  In  General. — 

In  this  chapter,  the  term  “depot-level  maintenanee  and  repair”  means  (exeept  as  provided 
in  subseetion  (b))  material  maintenanee  or  repair  requiring  the  overhaul,  upgrading,  or 
rebuilding  of  parts,  assemblies,  or  subassemblies,  and  the  testing  and  reclamation  of 
equipment  as  neeessary,  regardless  of  the  souree  of  funds  for  the  maintenanee  or  repair  or 
the  loeation  at  which  the  maintenance  or  repair  is  performed.  The  term  ineludes 

(1)  all  aspects  of  software  maintenanee  elassified  by  the  Department  of  Defense 
as  of  July  1,  1995,  as  depot-level  maintenanee  and  repair,  and 

(2)  interim  eontractor  support  or  contractor  logistics  support  (or  any  similar 
contractor  support),  to  the  extent  that  sueh  support  is  for  the  performanee  of 
services  described  in  the  preeeding  sentence. 

(b)  Exceptions. — 

(1)  The  term  does  not  inelude  the  procurement  of  major  modifications  or  upgrades 
of  weapon  systems  that  are  designed  to  improve  program  performanee  or  the 
nuelear  refueling  of  an  aircraft  carrier.  A  major  upgrade  program  eovered  by  this 
exception  eould  eontinue  to  be  performed  by  private  or  publie  seetor  activities. 

(2)  The  term  also  does  not  include  the  procurement  of  parts  for  safety 
modifications.  However,  the  term  does  include  the  installation  of  parts  for  that 
purpose. 
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Section  2466 


(link:  return  to  document) 

Limitations  on  the  performance  of  depot-level  maintenance  of  materiel 

(a)  Percentage  Limitation. — 

Not  more  than  50  percent  of  the  funds  made  available  in  a  fiscal  year  to  a  military 
department  or  a  Defense  Agency  for  depot-level  maintenance  and  repair  workload  may 
be  used  to  contract  for  the  performance  by  non-Federal  Government  personnel  of  such 
workload  for  the  military  department  or  the  Defense  Agency.  Any  such  funds  that  are  not 
used  for  such  a  contract  shall  be  used  for  the  performance  of  depot-level  maintenance  and 
repair  workload  by  employees  of  the  Department  of  Defense. 

(b)  Waiver  of  Limitation. — 

The  Secretary  of  Defense  may  waive  the  limitation  in  subsection  (a)  for  a  fiscal  year  if — 

(1)  the  Secretary  determines  that  the  waiver  is  necessary  for  reasons  of  national 
security;  and 

(2)  the  Secretary  submits  to  Congress  a  notification  of  the  waiver  together  with 
the  reasons  for  the  waiver. 

(c)  Prohibition  on  Delegation  of  Waiver  Authority. — 

The  authority  to  grant  a  waiver  under  subsection  (b)  may  not  be  delegated. 

(d)  Annual  Report. — 

(1)  Not  later  than  April  1  of  each  year,  the  Secretary  of  Defense  shall  submit  to 
Congress  a  report  identifying,  for  each  of  the  armed  forces  (other  than  the  Coast 
Guard)  and  each  Defense  Agency,  the  percentage  of  the  funds  referred  to  in 
subsection  (a)  that  was  expended  during  the  preceding  fiscal  year,  and  are 
projected  to  be  expended  during  the  current  fiscal  year  and  the  ensuing  fiscal  year, 
for  performance  of  depot-level  maintenance  and  repair  workloads  by  the  public 
and  private  sectors. 

(2)  Each  report  required  under  paragraph  (1)  shall  include  as  a  separate  item  any 
expenditure  covered  by  section  2474  of  this  title  that  was  made  during  the  fiscal 
year  covered  by  the  report  and  shall  specify  the  amount  and  nature  of  each  such 
expenditure. 
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Section  2470 


(link:  return  to  document) 


Depot-level  activities  of  the  Department  of  Defense:  authority  to  compete  for 
maintenance  and  repair  workloads  of  other  Federal  agencies 

A  depot-level  activity  of  the  Department  of  Defense  shall  be  eligible  to  compete  for  the 
performance  of  any  depot-level  maintenance  and  repair  workload  of  a  Federal  agency  for 
which  competitive  procedures  are  used  to  select  the  entity  to  perform  the  workload. 


154 


Section  2474 


(link:  return  to  document) 


Centers  of  Industrial  and  Technical  Excellence:  public-private  partnerships 


(a)  Designation. — 

(1)  The  Secretary  concerned,  or  the  Secretary  of  Defense  in  the  case  of  a  Defense 
Agency,  shall  designate  each  depot-level  activity  of  the  military  departments  and 
the  Defense  Agencies  (other  than  facilities  approved  for  closure  or  major 
realignment  under  the  Defense  Base  Closure  and  Realignment  Act  of  1990  (part 
A  of  title  XXIX  of  Public  Law  101-510;  10  U.S.C.  2687  note  ))  as  a  Center  of 
Industrial  and  Technical  Excellence  in  the  recognized  core  competencies  of  the 
designee. 

(2)  The  Secretary  of  Defense  shall  establish  a  policy  to  encourage  the  Secretary  of 
each  military  department  and  the  head  of  each  Defense  Agency  to  reengineer 
industrial  processes  and  adopt  best-business  practices  at  their  Centers  of  Industrial 
and  Technical  Excellence  in  connection  with  their  core  competency  requirements, 
so  as  to  serve  as  recognized  leaders  in  their  core  competencies  throughout  the 
Department  of  Defense  and  in  the  national  technology  and  industrial  base  (as 
defined  in  section  2500  (1)  of  this  title). 

(3)  The  Secretary  of  a  military  department  may  conduct  a  pilot  program, 
consistent  with  applicable  requirements  of  law,  to  test  any  practices  referred  to  in 
paragraph  (2)  that  the  Secretary  determines  could  improve  the  efficiency  and 
effectiveness  of  operations  at  Centers  of  Industrial  and  Technical  Excellence, 
improve  the  support  provided  by  the  Centers  for  the  armed  forces  user  of  the 
services  of  the  Centers,  and  enhance  readiness  by  reducing  the  time  that  it  takes  to 
repair  equipment. 


(b)  Public-Private  Partnerships. — 

(1)  To  achieve  one  or  more  objectives  set  forth  in  paragraph  (2),  the  Secretary 
designating  a  Center  of  Industrial  and  Technical  Excellence  under  subsection  (a) 
may  authorize  and  encourage  the  head  of  the  Center  to  enter  into  public-private 
cooperative  arrangements  (in  this  section  referred  to  as  a  “public-private 
partnership”)  to  provide  for  any  of  the  following: 
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(A)  For  employees  of  the  Center,  private  industry,  or  other  entities  outside 
the  Department  of  Defense  to  perform  (under  contract,  subcontract,  or 
otherwise)  work  related  to  the  core  competencies  of  the  Center,  including 
any  depot-level  maintenance  and  repair  work  that  involves  one  or  more 
core  competencies  of  the  Center. 

(B)  For  private  industry  or  other  entities  outside  the  Department  of 
Defense  to  use,  for  any  period  of  time  determined  to  be  consistent  with  the 
needs  of  the  Department  of  Defense,  any  facilities  or  equipment  of  the 
Center  that  are  not  fully  utilized  for  a  military  department’s  own 
production  or  maintenance  requirements. 

(2)  The  objectives  for  exercising  the  authority  provided  in  paragraph  (1)  are  as 
follows: 

(A)  To  maximize  the  utilization  of  the  capacity  of  a  Center  of  Industrial 
and  Technical  Excellence. 

(B)  To  reduce  or  eliminate  the  cost  of  ownership  of  a  Center  by  the 
Department  of  Defense  in  such  areas  of  responsibility  as  operations  and 
maintenance  and  environmental  remediation. 

(C)  To  reduce  the  cost  of  products  of  the  Department  of  Defense  produced 
or  maintained  at  a  Center. 

(D)  To  leverage  private  sector  investment  in — 

(i)  such  efforts  as  plant  and  equipment  recapitalization  for  a 
Center;  and 

(ii)  the  promotion  of  the  undertaking  of  commercial  business 
ventures  at  a  Center. 

(E)  To  foster  cooperation  between  the  armed  forces  and  private  industry. 

(3)  If  the  Secretary  concerned,  or  the  Secretary  of  Defense  in  the  case  of  a 
Defense  Agency,  authorizes  the  use  of  public-private  partnerships  under  this 
subsection,  the  Secretary  shall  submit  to  Congress  a  report  evaluating  the  need  for 
loan  guarantee  authority,  similar  to  the  ARMS  Initiative  loan  guarantee  program 
under  section  4555  of  this  title,  to  facilitate  the  establishment  of  public-private 
partnerships  and  the  achievement  of  the  objectives  set  forth  in  paragraph  (2). 


(c)  Private  Sector  Use  of  Excess  Capacity. — 

Any  facilities  or  equipment  of  a  Center  of  Industrial  and  Technical  Excellence  made 
available  to  private  industry  may  be  used  to  perform  maintenance  or  to  produce  goods  in 
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order  to  make  more  effieient  and  eeonomieal  use  of  Government-owned  industrial  plants 
and  eneourage  the  creation  and  preservation  of  jobs  to  ensure  the  availability  of  a 
workforce  with  the  necessary  manufacturing  and  maintenance  skills  to  meet  the  needs  of 
the  armed  forces. 

(d)  Crediting  of  Amounts  for  Performance. — 

Amounts  received  by  a  Center  for  work  performed  under  a  public-private  partnership 
shall  be  credited  to  the  appropriation  or  fund,  including  a  working-capital  fund,  that 
incurs  the  cost  of  performing  the  work.  Consideration  in  the  form  of  rental  payments  or 
(notwithstanding  section  3302  (b)  of  title  31)  in  other  forms  may  be  accepted  for  a  use  of 
property  accountable  under  a  contract  performed  pursuant  to  this  section. 

Notwithstanding  section  2667  (d)  [1]  of  this  title,  revenues  generated  pursuant  to  this 
section  shall  be  available  for  facility  operations,  maintenance,  and  environmental 
restoration  at  the  Center  where  the  leased  property  is  located. 

(e)  Availability  of  Excess  Equipment  to  Private-Sector  Partners. — 

Equipment  or  facilities  of  a  Center  of  Industrial  and  Technical  Excellence  may  be  made 
available  for  use  by  a  private-sector  entity  under  this  section  only  if — 

(1)  the  use  of  the  equipment  or  facilities  will  not  have  a  significant  adverse  effect 
on  the  readiness  of  the  armed  forces,  as  determined  by  the  Secretary  concerned  or, 
in  the  case  of  a  Center  in  a  Defense  Agency,  by  the  Secretary  of  Defense;  and 

(2)  the  private-sector  entity  agrees — 

(A)  to  reimburse  the  Department  of  Defense  for  the  direct  and  indirect 
costs  (including  any  rental  costs)  that  are  attributable  to  the  entity’s  use  of 
the  equipment  or  facilities,  as  determined  by  that  Secretary;  and 

(B)  to  hold  harmless  and  indemnify  the  United  States  from — 

(i)  any  claim  for  damages  or  injury  to  any  person  or  property 
arising  out  of  the  use  of  the  equipment  or  facilities,  except  under 
the  circumstances  described  in  section  2563  (c)(3)  of  this  title;  and 

(ii)  any  liability  or  claim  for  damages  or  injury  to  any  person  or 
property  arising  out  of  a  decision  by  the  Secretary  concerned  or  the 
Secretary  of  Defense  to  suspend  or  terminate  that  use  of  equipment 
or  facilities  during  a  war  or  national  emergency. 
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(f)  Exclusion  of  Certain  Expenditures  From  Percentage  Limitation. — 

Amounts  expended  for  the  performanee  of  a  depot-level  maintenance  and  repair 
workload  by  non-Federal  Government  personnel  at  a  Center  of  Industrial  and  Technical 
Excellence  under  any  contract  shall  not  be  counted  for  purposes  of  applying  the 
percentage  limitation  in  section  2466  (a)  of  this  title  if  the  personnel  are  provided  by 
private  industry  or  other  entities  outside  the  Department  of  Defense  pursuant  to  a  public- 
private  partnership. 


(g)  Construction  of  Provision. — 

Nothing  in  this  section  may  be  construed  to  authorize  a  change,  otherwise  prohibited  by 
law,  from  the  performance  of  work  at  a  Center  of  Industrial  and  Technical  Excellence  by 
Department  of  Defense  personnel  to  performance  by  a  contractor. 
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Appendix  C:  Summary  of  DoD  Policy  Documents 


DoD  Directive  4151.18 
Maintenance  of  Military  Materiel 

This  directive,  published  by  the  Under  Secretary  of  Defense  for  Acquisition 
Technology  and  Logistics  (USD  AT&L)  provides  guidance  for  the  maintenance  of 
weapon  systems  and  specifically  includes  software  within  its  purview.  Key  points: 


•  Establishes  as  DoD  policy  that  “Maintenance  tasks  restore  safety  and  reliability” 

•  Provides  guidance  regarding  depot  maintenance  core  capabilities. 

•  Core  capabilities  must  be  identified  as  early  as  possible  in  the  acquisition  life 
cycle  and  be  established  in  the  public  sector  not  later  than  four  years  after  Initial 
Operational  Capability. 

•  Maintenance  of  all  weapon  systems  related  to  that  capability  need  not  be 
performed  in  a  public  facility.  Rather,  the  capability  to  perform  that  maintenance 
must  be  retained  in  those  facilities. 

•  Exempts  workloads  associated  with  a  core  capability  from  cost  studies  directed  by 
the  Office  of  Management  and  Budget  circular  A-76  dated  May  2003. 

•  For  that  portion  of  the  maintenance  workload  not  necessary  for  sustaining  a  core 
capability,  factors  such  as  cost,  performance,  and  responsiveness  should  be 
considered. 

•  The  source  of  repair  selected  for  non-core  sustaining  workload  should  minimize 
risk  while  providing  the  best  value  to  the  government. 
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DoD  Directive  5000.01 


The  Defense  Acquisition  System 

This  document  is  essentially  an  executive  summary  of  the  acquisition  system.  It 
defines  the  acquisition  policy  as  existing  to  . .  manage  the  nation’s  investments  in 
technologies,  programs  and  product  support  necessary  to  achieve  the  National  Security 
Strategy.”  Key  points: 


•  Identifies  five  attributes  which  govern  the  acquisition  system:  Flexibility, 
responsiveness,  innovation,  discipline,  and  streamlined  and  effective 
management. 

•  Performance  based  logistics  is  identified  as  a  policy  of  the  acquisition  system. 

•  “Sustainment  strategies  shall  include  the  best  use  of  public  and  private  sector 
capabilities  through  government/industry  partnering  initiatives,  in  accordance 
with  statutory  requirements.” 
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DoD  Instruction  5000.02 


Operation  of  the  Defense  Acquisition  System 

DoD  Directive  5000.01  describes  the  acquisition  system;  DoD  Instruction  5000.02 
defines  how  the  systems  will  be  operated.  While  this  instruction  describes  the  entire 
acquisition  lifecycle,  this  summary  will  focus  exclusively  on  the  operations  and  support 
phase  as  it  is  pertinent  to  the  subject  of  software  maintenance  as  a  core  logistics 
capability. 


•  The  operations  and  support  phase  is  intended  to  meet  material  readiness  and 
operational  support  performance  requirements  in  the  most  cost  effective  manner. 

•  Entrance  into  this  phase  occurs  when  a  system  has  an  approved  Capability 
Production  Document  (CPD),  Life-Cycle  Sustainment  Plan  (LCSP)  and  a 
successful  Full-Rate  Production  Decision. 

•  Considerations  for  life-cycle  sustainment  should  include  supply,  maintenance, 
transportation,  sustaining  engineering,  data  management,  configuration 
management,  HIS,  environment,  safety,  occupational  health,  protection  of  critical 
program  information,  supportability,  and  interoperability. 
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DODI  4151.20 


Depot  Maintenance  Core  Capabilities  Determination  Process 


DODI  4151.20  interprets  and  implements  Title  10  Section  2464. 


•  Defines  a  core  logistics  capability  as: 

The  depot  maintenance  capability  (including  personnel,  equipment, 
and  facilities)  maintained  by  the  Department  of  Defense  at  government 
owned,  government  operated  facilities  as  the  ready  and  controlled 
source  of  technical  competence  and  resources  necessary  to  ensure 
effective  and  timely  response  to  a  mobilization,  national  defense 
contingency  situation  and  other  emergency  requirements.  Depot 
maintenance  for  the  designated  weapon  systems  and  other  military 
equipment  is  the  primary  workload  assigned  to  DoD  depots  to  support 
core  depot  maintenance  capabilities. 

•  Mirrors  the  intent  of  Title  10  section  2464  in  emphasizing  that  the  government,  in 
time  of  need,  will  have  available  a  workforce  and  facilities  ready  to  handle 
increased  workloads  associated  with  a  wartime  scenario.  This  capability  resides 
within  government  owned  facilities  and  must  be  manned  by  government 
employees. 

•  Reiterates  the  law  by  designating  software  maintenance  as  a  depot  level 
maintenance  function. 

•  Makes  a  distinction  between  capability  and  capacity  which  is  central  to  the 
understanding  of  core. 

o  Capability  is  defined  as  the  personnel,  facilities,  processes  and  technology 
required  to  perform  a  particular  category  of  work  necessary  to  support 
strategic  and  contingency  plans. 

o  Capacity  as  the  amount  of  work  which  can  be  performed  within  a  given 
amount  of  time  and  is  expressed  in  terms  of  Direct  Labor  Hours  (DLH). 

•  The  combination  of  capability  and  capacity  defines  both  what  and  how  much 
logistic  support  DoD  must  maintain  to  support  JCS  scenarios. 
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DODI  4151.21 


Public-Private  Partnerships  for  Depot-Level  Maintenance 


•  Defines  a  public-private  partnership  for  depot-level  maintenance  as: 

o  A  “cooperative  arrangement  between  an  organic  depot-level  maintenance 
activity  and  one  or  more  private  sector  entities  to  perform  DoD  or 
Defense-related  work  and/or  utilize  DoD  depot  facilities  and  equipment.” 

•  Partnerships  are  directed  whenever  it  is  cost  effective  and  can  provide  improved 
warfighter  support  while  utilizing  the  government’s  facilities. 

•  A  partnership  will  be  formed  around  those  activities  identified  as  core 
competencies. 
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Appendix  D:  Summary  of  Relevant  Air  Force  Instructions 


AFPD  63-01/20-1 


Acquisition  and  Sustainment  Life  Cycle  Management 

This  Air  Force  directive  further  refines  and  implements  DoD  acquisition  policy 
and  within  the  scope  of  this  research  was  primarily  used  as  a  source  of  definitions. 


AFI  63-101 

Acquisition  and  Sustainment  Life  Cycle  Management 

The  purpose  of  this  instruction  is  to  implement  the  policies  established  in 
AFPD  63-01.  While  this  document  goes  into  great  detail  regarding  the  entire  system  life- 
cycle,  this  summary  focuses  on  those  aspects  related  to  core  capabilities  and  software 
specific  aspects  of  the  life-cycle.  This  document  served  as  a  key  source  of  definitions 
relevant  to  our  research  objectives.  Key  points: 


•  A  DSOR  [Depot  Source  of  Repair]  decision  for  all  depot-level  maintenance  for 
hardware  and  software,  with  special  attention  to  Title  10  Section  2464  (core 
capability)  and  Title  10  Section  2466  (50/50  requirement),  is  essential  to  the  life 
cycle  sustainment  strategy.” 

•  DSOR  process  should  consider  at  a  minimum  public  law,  long-term  depot 
strategy,  cost,  mission  assignment  alignment,  environmental  impacts,  and  specific 
weapon  system  requirements. 

•  Source  of  repair  assignment  process  should  be  based  on  multiple  factors  and  not 
as  a  competition  between  an  organic  and  contract  depot. 
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•  Types  of  depot  maintenance  -  programmed  depot  maintenance,  analytical 
condition  inspection,  speedline,  major  overhaul  and  repair,  repair  of  reparable, 
contract/depot  field  teams,  over  and  above,  extended/negotiated  warranty  costs, 
software  maintenance,  and  disposal. 

•  For  the  purposes  of  satisfying  Title  10  Section  2466,  work  done  in  DoD 
maintenance  depots  is  defined  as  the  workload  funded  through  the  capital 
working  fund  and  accomplished  by  employees  of  the  SECAF  designated  Centers 
of  Industrial  and  Technical  Excellence. 


AFI  63-107  fSORAP) 

Integrated  Product  Support  Planning  and  Assessment 

This  document  is  included  in  this  section  because  the  Source  of  Repair 
Assignment  Process  (SORAP)  decision  is  what  ultimately  determines  whether  software 
will  be  sustained  in  a  public  or  private  depot.  As  laid  out  in  AFI  63-101,  the  SORAP  is 
designed  to  consider  many  factors  when  determining  a  source  of  repair  such  as  law,  long 
term  depot  strategy,  cost,  and  system  requirements.  AFI  63-107  re-emphasizes  that  the 
SORAP  is  not  a  competition  between  public  and  private  sources  of  depot  maintenance. 

The  Program  Manager  (PM)  is  the  individual  responsible  for  initiating  and 
completing  the  SORAP,  and  is  required  to  consider  all  viable  sustainment  options  prior  to 
submitting  a  source  of  repair  recommendation  to  the  SORAP  committee. 

Five  situations  where  SORAP  is  required: 

1.  New  Starts  (New  Acquisitions):  The  acquisition  of  any  weapon  system,  item 
component,  system,  subsystem,  or  software  that  will  result  in  a  requirement 
for  depot-level  maintenance. 


165 


2.  Modification  Follow-on  Workloads:  Depot  maintenance  workloads 
generated  as  a  result  of  a  modification  installation. 

3.  Overseas  Workload  Program:  SORAPs  are  required  for  any  new,  modified, 
or  shift  in  source  of  repair  that  involves  the  potential  for  accomplishment  of 
depot-level  maintenance  by  a  source  outside  the  United  States. 

4.  Modifications/Reconfigurations:  The  modification  of  a  weapon  system, 
subsystem,  item  or  component,  which  is  considered  depot-level  maintenance, 
is  subject  to  SORAP  requirements. 

5.  Workload  Shifts:  Permanent  change  in  the  officially  designated  source  of 
repair,  or  source  of  modification,  can  only  be  accomplished  through  a  SORAP 
when  such  change  involves  a  public  depot.  Specifically,  a  SORAP  is  required 
for  proposed  changes  in  the  source  of  repair  resulting  in  one  of  the  following 
types  of  shifts: 

a.  From  assigned  organic  depot  to  another  organic  depot. 

b.  From  assigned  organic  depot  to  a  contract. 

c.  From  contract  source  of  repair  to  an  organic  depot. 
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Appendix  E:  Summary  of  GAO  Reports 


Privatization  and  the  Debate  over  the  Public-Private  Mix  tGAO/T-NSIAD-96-148) 

This  GAO  report  is  a  summary  of  the  testimony  before  the  subcommittee  on 
Readiness  and  the  Committee  on  Armed  Services  in  the  U.S.  Senate.  There  are  four 
general  themes  in  this  report: 


•  DoD’s  depot  maintenance  management  model  in  the  post  cold  war  era 

•  The  extent  to  which  DoD’s  proposed  depot  maintenance  policy  is 
consistent  with  congressional  direction  and  guidance. 

•  The  savings  that  DoD  is  anticipating  from  privatization  of  depot 
maintenance  activities. 

•  The  cost-effectiveness  of  privatization-in-place  as  an  alternative  for 
closing  depots. 


This  report  was  conducted  in  1996  and  therefore  the  context  is  that  of  a  military 
fresh  out  of  the  Cold  War  and  looking  to  re-shape  itself  both  in  combat  capability  as  well 
as  logistic  capability.  As  the  number  of  major  acquisition  programs  decreased,  the  DoD 
became  concerned  that  the  industrial  base  could  not  be  maintained  and  saw  depot 
maintenance  as  way  to  keep  that  critical  function  viable.  An  added  benefit  the  proponents 
of  this  policy  envisioned  was  cost  savings;  assuming  the  private  sector  could  perform  this 
work  more  cost  effectively. 

Of  the  four  main  areas  of  this  report,  the  examination  of  the  consistency  between 
DoD  and  congressional  guidance  as  well  as  the  anticipated  savings  from  privatization  are 
most  applicable  to  this  study  in  so  far  as  they  provide  a  history  of  the  friction  between  the 
law  and  reality  as  well  as  an  examination  of  one  of  the  main  benefits  of  privatization  - 
cost. 
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At  the  time  of  this  report,  the  GAO  observed  a  clear  shift  in  DoD  policy  towards 


private  sector  depot  maintenance.  It  was  the  view  of  the  GAO  that  this  shift  in  policy 
could  potentially  exacerbate  existing  excess  capacity  problems  and  inefficiencies  inherent 
in  an  underutilized  depot  maintenance  structure.  Additionally,  the  GAO  found  the  DoD 
policy  to  be  inconsistent  with  congressional  guidance  in  the  area  of  public-private 
competitions  for  non-core  workloads. 

In  terms  of  cost  effectiveness  of  private  depots,  the  GAO  found  inconsistencies 
with  the  basis  of  cost  comparisons  leading  to  a  more  pessimistic  expectation  of  cost 
savings.  The  GAO  argued  the  DoD  used  outsourcing  of  such  services  as  vehicle 
maintenance  and  food  services  as  the  basis  of  cost  savings.  The  GAO  used  more 
comparable  private-public  program  competitions  and  found  the  following: 


•  67%  of  competitions  were  won  by  the  DoD  with  the  average  bid  40% 
lower  than  the  closest  competitor. 

•  23%  of  the  programs  no  private  bids  were  offered  and  35%  included  only 
one  private  bid. 

•  62%  of  items  repaired  by  both  private  and  public  depots  were  maintained 
less  expensively  in  the  public  sector. 


Finally,  software  maintenance,  while  only  mentioned  once  in  the  document,  was  a 

private  sector  function  in  1996  as  the  following  indicates: 

DoD  annually  spends  about  $15  billion — or  about  6  percent  of  its  $243 
billion  fiscal  year  1996  budget — on  depot  maintenance  activities.  About 
$2  billion  of  this  amount  includes  contractor  logistics  support,  interim 
contractor  support,  and  funds  for  labor  associated  with  the  installation  of 
some  major  modifications  and  parts  of  software  maintenance,  which  are 
contracted  to  the  private  sector  using  procurement,  rather  than  operation 
and  maintenance  funds. 
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DoD’s  Policy  Report  Leaves  Future  Role  of  Depot  System  Uncertain  (GAO/NSIAD- 
96-165) 

This  GAO  report  is  an  analysis  of  the  Policy  Regarding  Performance  of  Depot- 
Level  Maintenance  and  Repair  report  issued  by  the  DoD  and  was  required  by  section  311 
of  the  National  Defense  Authorization  Act  of  Fiscal  Year  1996.  This  report  is  an  in-depth 
analysis  of  the  preliminary  findings  that  were  presented  in  GAO/T-NSIAD-96-148 
Privatization  and  the  Debate  Over  the  Public-Private  Mix.  As  such,  the  main  points 
remain  the  same  as  those  from  the  testimony  previously  covered. 


Some  additional  findings  in  this  report  that  are  of  interest  to  this  paper  are: 


•  DoD  policy  establishing  total  life-cycle  contractor  logistic  support  as  the  preferred 
model  for  maintaining  new  systems  not  identified  as  core. 

•  DoD  policy  shift  toward  a  greater  mix  of  private  depots  which  is  reflected  by: 

o  A  call  for  minimum  core  requirements 

o  Redefining  core  to  allow  for  privatizing  mission  essential  requirements 
previously  defined  as  core. 

o  Limit  public  depots  from  competing  with  the  private  sector  for  noncore 
workloads. 

o  Provide  a  preference  for  privatizing  depot  maintenance  and  repair  for  new 
systems. 

o  Provide  disincentives  for  depots  to  compete. 

•  DoD  policy  moved  source  of  repair  decisions  from  service  logistics  chief  (in 
conjunction  with  functional  organic  depot  maintenance  and  business  managers)  to 
the  service  acquisition  representative  responsible  for  a  new  weapon  system. 

•  Identifies  core  capabilities  as  required  to  sustain  in-house  technical  competence- 
skilled  maintenance  workers,  engineers  contracting  officials  and  program 
managers-to  minimize  technological  risks. 
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More  Comprehensive  and  Consistent  Workload  Data  Needed  for  Decisionmakers 


(GAQ/NSIAD-96-166) 

This  GAO  report  is  the  assessment  of  the  DoD  report  Depot  Maintenance  and 
Repair  Workload  required  by  seetion  3 1 1  of  the  National  Defense  Authorization  Aet  for 
Fiscal  Year  1996.  The  report  focused  on  the  following  areas: 


•  The  need  for  and  effect  of  the  60/40  legislative  requirement  concerning  the 
allocation  of  depot  maintenance  workloads  between  the  public  and  private 
sectors. 

•  Historical  public  and  private  sector  depot  maintenance  workloads  allocations. 

•  Projected  public  and  private  depot  maintenance  workload  allocations. 


Of  note  from  this  report,  the  Air  Force,  in  1997,  was  projected  to  have  a  public- 
private  mix  of  depot  maintenance  of  46/54.  Additionally,  the  GAO  reported  that  the  Air 
Force  intended  to  privatize  five  prototype  workloads,  one  of  which  was  software. 
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Uncertainties  and  Challenges  DoD  Faces  in  Restructuring  Its  Depot  Maintenance 
Program  tGAO/T-NSIAD-97-112t 

This  testimony  before  the  House  of  Representatives  Subcommittee  on  Readiness 
and  the  U.S.  Senate  Committee  on  Armed  Services  covered  four  main  areas. 


•  DoD  plans  for  eliminating  costly  depot  maintenance  excess  capacity. 

•  DODs  progress  in  finalizing  a  new  depot  workload  allocation  policy. 

•  DODs  current  approach  for  allocating  maintenance  workloads  for  new  and 
existing  systems. 

•  DoD  estimates  that  billions  can  be  saved  by  outsourcing  depot  maintenance. 

This  report  highlights  the  fact  that  in  1997,  policy  regarding  mix  of  public-private 

workload  and,  to  a  lesser  extent,  identification  of  core  depot  maintenance  capabilities  was 

very  much  in  flux.  In  fact,  the  report  states  that  program  officials  from  the  C-17,  F-22, 

and  F/A-18E/F  were  delaying  final  support  decisions  in  part  because  of  the  uncertain 

status  of  DoD  core  policies. 


Additionally,  the  testimony  evolved  its  definition  of  depot  maintenance  to  read: 


Depot  maintenance  is  a  vast  undertaking  that  requires  extensive  shop 
facilities,  specialized  equipment,  and  highly  skilled  technical  and 
engineering  personnel  to  perform  major  overhauls  of  weapon  systems  and 
equipment,  to  completely  rebuild  parts  and  end  items,  to  modify  systems 
and  equipment  by  applying  new  or  improved  components,  to  manufacture 
parts  unavailable  from  the  private  sector,  and  to  program  the  software  that 
is  an  integral  part  of  today’s  complex  weapon  systems. 

This  definition  conspicuously  omits  the  term  maintenance  after  the  word  software  and 

insinuates  that  depot  maintenance  involves  all  manner  of  software  programming. 
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DoD  Shifting  More  Workload  for  New  Weapon  Systems  to  the  Private  Sector 


(GAQ/NSIAD-98-8) 

This  report  is  one  in  a  series  of  reports  by  the  GAO  addressing  DoD’s  depot 
maintenance  policies,  outsourcing  plans,  depot  closures,  and  the  allocation  of  work 
between  the  public  and  private  sectors. 

This  report  once  again  highlights  an  ongoing  debate  between  DoD  and  Congress 
regarding  the  size,  composition,  and  allocation  of  depot  maintenance  workload  between 
the  public  and  private  sectors.  A  1995  report  by  the  Commission  on  Roles  and  Missions 
titled  Directions  for  Defense  estimated  the  DoD  could  reduce  depot  maintenance  costs  by 
20-40%  by  outsourcing  work  in  a  competitive  environment.  The  GAO  disagreed  with  this 
assessment  charging  that  in  some  cases  outsourcing  practices  could  actually  increase  the 
cost  of  depot  maintenance.  In  response  to  this  debate,  the  1998  Defense  Authorization 
Act  provided  the  following  changes  to  various  depot  maintenance  requirements: 


•  Created  section  2460  in  Title  10  establishing  a  statutory  definition  of  depot-level 
maintenance  which  included,  among  other  types  of  work,  certain  software 
maintenance  while  excluding  major  system  upgrades. 

•  Amended  10  U.S.C.  2464  to  provide  for  a  DoD-maintained  core  logistics 
capability  that  is  required  to  be  government  owned  and  operated. 

•  Amended  10  U.S.C  2466  to  allow  DoD  to  use  up  to  50  percent  of  its  depot 
maintenance  funds  for  private  sector  performance  of  work 

The  GAO  research  showed  that  as  of  1997,  13  of  25  major  Air  Force  acquisition 

programs  had  either  selected  or  were  leaning  towards  private  sector  depot  maintenance 

constituting  52  percent  of  the  programs  studied.  This  is  compared  to  just  4  of  25,  or  16 

percent,  selecting  or  leaning  towards  the  public  sector.  In  addition,  the  report  states  the 
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C-17  program  put  off  a  decision  on  its  source  of  repair  until  2003  or  later  because  of 
uncertainty  with  DoD  policies. 

Also  of  note  in  this  report  was  that  nearly  76  percent  of  program  managers  DoD 
wide  that  had  finalized  their  source  of  repair  decision  (1)  did  not  plan  to  assess  core  and 
were  moving  ahead  without  a  core  determination  (2)  were  unsure  of  their  plans  or  (3) 
were  uncertain  about  how  or  whether  to  consider  core.  Some  even  responded  they  were 
not  sure  what  the  term  “core”  meant. 

Finally,  the  GAO  found  that  many  programs  were  not  planning  to  buy  technical 
data  that  could  help  them  avoid  sole-sourcing  maintenance  work  to  the  contractor  that 
developed  the  system.  There  were  varying  reasons  for  not  purchasing  data  rights  typically 
centering  on  the  cost  associated  with  the  data  coupled  with  a  perceived  lack  of  need. 
Ultimately,  the  GAO  assessed  not  purchasing  the  technical  data  would  result  in  a  higher 
life-cycle  support  cost  and  difficult  logistics  decisions  in  the  future. 
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Air  Force  Faces  Challenges  in  Managing  to  50-50  Ceiline  (GAO/T-NSIAD-00-112) 


The  data  in  this  GAO  report  is  a  result  of  testimony  before  the  U.S.  House  of 
Representatives  Subcommittee  on  Readiness,  and  the  U.S.  Senate  Committee  on  Armed 
Services.  The  content  of  this  testimony  deal  exclusively  with  a  fiscal  year  2000  waiver 
request  to  the  50/50  rule  by  the  Secretary  of  the  Air  Force.  The  only  useful  data  to  this 
paper  from  the  GAO  report  is  contained  in  Figure  32,  which  shows  the  trend  of 
increasing  contractor  involvement  in  depot  maintenance. 


Fiscal  Year 

Figure  32.  Contractor  Depot  Maintenance  Workload  Allocations  from  1991  to  2000 
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Air  Force  Report  on  Contractor  Support  is  Narrowly  Focused  (GAO/NSI AD-00- 
115) 

This  report  to  Congressional  Committees  was  in  response  of  section  344  of  the 
National  Defense  Authorization  Act  for  Fiscal  Year  2000  which  required  the  Secretary  of 
the  Air  Force  to  provide  a  report  to  Congress  identifying  all  Air  Force  programs  that  were 
currently  using  or  planning  to  use  Total  System  Performance  Responsibility  (TSPR)  or 
similar  contractor  support  programs.  Additionally,  the  Air  Force  report  was  to,  among 
other  things;  evaluate  how  these  programs  support  warfighting  readiness  and  the  process 
and  criteria  used  by  the  Air  Force  to  determine  whether  government  or  the  private  sector 
can  perform  logistics  management  functions  more  cost-effectively.  The  GAO  was  then 
tasked  to  evaluate  the  Air  Force  report  to  Congress. 

Much  of  this  GAO  report  was  outside  the  purview  of  this  paper.  There  was  one 
finding  of  interest  concerning  government  depot  maintenance,  however.  In  the  process  of 
evaluating  how  programs  such  as  TSPR  might  affect  core  logistics  management,  the 
GAO  identified  a  concern  within  Air  Force  Material  Command  that  depots  were  not 
receiving  work  involving  new,  advanced  technology  weapon  systems  they  would  need  to 
have  if  they  were  to  establish  and  maintain  core  capabilities  in  these  areas.  An  excerpt 
from  a  9  Feb  2000  memorandum  from  the  Ogden  Air  Logistics  Center  to  Headquarters, 
Air  Force  Materiel  Commanded  stated: 

Infusion  of  new  technology  workloads  from  new  weapon  systems  is 
essential  to  maintain  core.  Therefore  the  future  of  the  [air  logistics  center] 
is  contingent  upon  acquiring  workloads  in  each  technical  repair  center  that 
will  continue  to  provide  a  viable  organic  source  of  repair  for  the  using 
commands.  If  an  [air  logistics  center]  is  determined  core  or  best  value  in  a 
particular  technology,  then  any  new  weapon  system  acquired  that  has  the 
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associated  technology  should  have  the  respective  core  allocation  from  day 
one  of  the  sustainment  life  cycle.  The  core  determination  is  weighted 
heavily  towards  older  high  surge  workloads.  Depots  are  provided  new 
workloads  often  only  after  the  original  equipment  manufacturer  loses 
interest,  [pg  13] 


Air  Force  Waiver  to  U.S.C  2466  (GAO/NSIAD-00-152R) 

This  GAO  letter  to  members  of  the  House  of  Representatives  is  an  assessment  of 
the  Air  Force  waiver  to  10  U.S.C  2466  which  caps  at  50  percent  all  depot  maintenance 
expenditures  within  the  private  sector  per  fiscal  year.  This  letter  serves  to  highlight  an 
ongoing  privatization  trend  within  the  Air  Force  in  the  early  2000’s. 

A  noteworthy  finding  in  this  GAO  letter  was  a  massive  increase  in  private  sector 
depot  maintenance  spending  in  a  four  year  period.  In  1996,  the  Air  Force  spent 
approximately  $600  million  on  long-term  depot  maintenance  contracts  for  new  systems. 
By  2000,  however,  that  number  had  increased  to  $1.1  billion,  an  increase  of  83  percent.  It 
also  showed  this  trend  to  continue  at  least  through  2004  with  an  average  of  48  percent 
allocation  of  depot  maintenance  workload  to  the  private  sector  during  that  timeframe. 
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Actions  Needed  to  Overcome  Capability  Gaps  in  the  Public  Depot  System  (GAO-02- 
105) 

This  GAO  report  to  Congressional  Committees  was  in  response  to  coneem  from 
members  of  Congress  about  the  need  to  eontinue  the  performance  of  mission-essential,  or 
core,  maintenance  activities  in  military  depots  and  the  long-term  viability  of  military 
industrial  facitlities  in  light  of  the  DoD’s  increased  reliance  on  the  private  sector  to 
accomplish  logistics  support  activities  such  as  the  maintenance  of  weapon  systems. 

One  area  of  concern  to  the  GAO  was  the  DoD’s  use  of  “like”  workloads  to  satisfy 
the  core  requirements.  The  GAO  used  the  example  of  the  DoD  using  workload  on  the  C- 
141  and  C-5  to  satisfy  core  capability  workload  on  the  C-17.  The  DoD’s  provided  an 
analogy  of  an  auto  mechanic  who  can  perform  work  on  Chrysler,  Ford,  and  General 
Motors  products,  if  the  mechanic  has  tools,  facilities,  and  knowledge.  They  asserted  the 
skills,  facilities,  and  knowledge  are  transferable  and  the  same  holds  true  within  the  DoD. 

Additionally,  the  GAO  found  fault  the  DoD’s  use  of  a  risk  assessment  when 
determining  whether  maintaining  a  system  was  core.  The  GAO  found  that  the  DoD  was 
assessing  whether  the  private  sector  could  provide  logistics  capability  for  mission 
essential  items  at  an  acceptable  level  of  risk.  Further,  GAO  found  that  this  type  of  risk 
assessment  was  not  consistent  with  U.S.C.  10  2464  and  ultimately  the  DoD  agreed  to 
remove  risk  from  its  core  determination  process. 

Finally,  this  report  identified  shortfalls  within  the  DoD,  and  the  Air  Force 
specifically,  in  the  area  of  software  maintenance.  In  2001,  for  example,  the  Air  Force 
forecast  an  800,000-hour  shortfall  in  depot-level  software  maintenance  workload.  The 
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shortfall  was  primarily  due  to  a  lack  of  capability  to  accomplish  that  much  workload.  Air 
Force  officials  repeatedly  identified  shortfalls  in  qualified  software  technicians  and 
engineers  as  one  of  their  most  severe  concerns  at  the  depots  [pg  23].  While  recruiting  in 
general  was  not  a  problem  for  the  depots,  officials  did  note  difficulty  in  hiring  workers 
with  software  maintenance  skills.  A  national  shortage,  at  the  time,  of  software  engineers 
meant  the  depots  were  competing  with  the  private  sector  for  workers. 


DoD  Should  Strengthen  Policies  for  Assessine  Technical  Data  Needs  to  Support 
Weapon  Systems  tGAO-06-839) 


This  GAO  report  to  Congressional  Committees  highlights  the  implications  of 
changing  policies  and  laws  on  programs  with  long  acquisition  timelines.  It  also 
highlights  the  need  to  purchase  technical  data  rights  for  effective  system  life-cycle 
sustainment.  In  particular,  this  section  will  highlight  the  plight  of  the  F-22,  although  the 
GAO  raised  similar  issues  with  other  programs  contemporary  to  the  F-22. 


F-22  aircraft:  The  acquisition  of  the  Air  Force’s  F-22  aircraft  did  not 
include  all  of  the  technical  data  needed  for  establishing  required  core 
capability  workload  at  Air  Force  depots.  Early  in  the  F-22  aircraft’s 
acquisition,  the  Air  Force  planned  to  use  contractors  to  provide  needed 
depot-level  maintenance  and  therefore  decided  not  to  acquire  some 
technical  data  rights  from  sub- vendors  in  order  to  reduce  the  aircraft’s 
acquisition  cost.  Subsequently,  however,  the  Air  Force  determined  that 
portions  of  the  F-22  workload  were  needed  to  satisfy  core  depot 
maintenance  requirements.  The  Air  Force  is  currently  negotiating 
contracts  for  the  technical  data  rights  needed  to  develop  depot-level 
maintenance  capability.  While  the  Air  Force  has  negotiated  contracts  to 
acquire  technical  data  for  four  F-22  aircraft  components,  F-22  program 
officials  expressed  concern  that  it  may  become  difficult  to  successfully 
negotiate  rights  to  all  components. 
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Additionally,  the  GAO  identified  several  factors  which  may  complicate  program 
managers’  decisions  on  long-term  technical  data  rights  for  weapon  systems.  These  factors 
include  the  following: 


•  The  contractor’s  interests  in  protecting  its  intellectual  property  rights.  Because 
contractors  need  to  protect  their  intellectual  property  from  uncompensated  use, 
they  often  resist  including  contract  clauses  that  provide  technical  data  rights  to  the 
government. 

•  The  extent  to  which  the  system  being  acquired  incorporates  technology  that  was 
not  developed  with  government  funding.  According  to  DoD’s  acquisition 
guidance  the  government’s  funding  of  weapon  system  development  determines 
the  government’s  rights  to  technical  data.  Weapon  systems  are  frequently 
developed  with  some  mix  of  contractor  and  government  finding,  which  may 
present  challenges  to  DoD  in  negotiating  technical  data  rights  with  the  contractor. 

•  The  potential  for  changes  in  the  technical  data  over  the  weapon  system’s  life 
cycle.  The  technical  data  for  a  weapon  system  may  change  over  its  life  cycle,  first 
as  the  system’s  technology  matures  and  later  as  the  system  undergoes 
modifications  and  upgrades  to  incorporate  new  technologies  and  capabilities.  The 
potential  for  changes  in  technical  data  present  challenges  concerning  when  the 
government  should  take  delivery  of  technical  data,  the  format  used  to  maintain 
technical  data,  and  whether  the  data  should  be  retained  in  a  government  or 
contractor  repository. 

•  The  extent  to  which  the  long-term  sustainment  strategy  may  require  rights  to 
technical  data  versus  access  to  the  data.  According  to  Army  officials,  access  to 
contractor  technical  data  is  sometimes  presented  as  an  alternative  to  the 
government  taking  delivery  of  the  data.  These  officials  noted  that  while  access  to 
technical  data  may  allow  for  oversight  of  the  contractor  and  may  reduce  the 
program  manager’s  data  management  costs,  it  may  not  provide  the  government 
with  rights  to  use  the  technical  data  should  a  change  in  the  sustainment  plan 
become  necessary. 

•  The  numerous  funding  and  capability  trade-offs  program  managers  face  during 
the  acquisition  of  a  weapon  system.  Program  managers  are  frequently  under 
pressure  to  spend  limited  acquisition  dollars  on  increased  weapon  system 
capability  or  increased  numbers  of  systems,  rather  than  pursuing  technical  data 
rights. 

•  The  long  life  cycle  of  many  weapon  systems.  With  weapon  systems  staying  in 
DoD’s  inventory  for  longer  periods — ^up  to  40  years,  it  may  be  difficult  for  the 
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program  manager  to  plan  for  future  contingencies  such  as  modifications  and 
upgrades,  spare  parts  obsolescence,  diminishing  manufacturing  support,  and 
diminishing  maintenance  support. 
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DoD  Needs  to  Reexamine  Its  Extensive  Reliance  on  Contractors  and  Continue  to 
Improve  Management  and  Oversight  fGAO-08-572T) 

This  GAO  report  is  a  summary  of  testimony  provided  before  Subcommittee  on 
Readiness  and  the  Committee  on  Armed  Services  of  the  House  of  Representatives.  It 
takes  a  broad  look  at  core  capabilities  throughout  the  DoD,  not  just  focusing  on  core 
logistics  capabilities.  The  report  does,  however,  spend  some  time  analyzing  the 
challenges  facing  the  DoD  with  respect  to  developing  core  logistics  capabilities  and 
specifically  how  much  work  should  be  done  in-house  and  to  what  extent  outsourcing  of 
labor  has  been  cost  effective. 

The  GAO  cites  three  factors  as  influencing  the  DoD  trend  toward  contractor 
support  for  depot  level  maintenance:  1)  DoD  guidance  emphasizing  outsourcing  2)  A 
lack  of  technical  data  and  modernized  facilities  to  perform  work  on  new  systems  3) 
Reductions  in  maintenance  workers  at  government  facilities.  In  fact,  the  GAO  cites  a  246 
percent  increase  in  funding  for  private  sector  contracts  for  depot  maintenance  between 
1987  and  2000.  The  funding  for  public  depots,  however,  increased  by  only  89  percent 
during  the  same  timeframe;  a  clear  indication  of  the  shift  in  emphasis  away  from  in-house 
maintenance. 

Another  significant  finding  by  the  GAO  is  that  the  DoD  did  not,  as  of  2008,  had 
not  comprehensively  identified  what  depot  maintenance  should  be  performed  in-house. 
This  made  it  difficult  for  the  GAO  to  determine  what  maintenance  activities  being 
performed  by  contractors  should  in  fact  be  done  by  government  personnel. 
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Issues  and  Options  for  Reporting  on  Military  Depots  (GAO-08-761R) 

This  briefing  to  Congressional  Committees  was  in  response  to  the  2008  National 
Defense  Authorization  Act  which  required  the  GAO  to  review  and  make 
recommendations  regarding  the  reports,  assessments,  analyses,  and  documents  used  for 
determining  the  compliance  of  the  Department  of  Defense  (DoD)  and  military 
departments  with  the  percentage  limitation  in  10  U.S.C.  2466  -frequently  referred  to  as 
the  50/50  requirement. 

The  briefing  had  three  key  objectives.  Objective  3  is  of  particular  interest  to  this 
paper  as  it  offers  Congress  some  key  issues  to  consider  in  the  ongoing  debate  over  the 
correct  mix  of  private  and  public  workloads  as  well  as  core  capabilities.  The  issues,  as 
laid  out  by  GAO  are: 

•To  what  extent  are  50/50  and  core  still  relevant  for  assessing  a  required  level  of 
organic  maintenance  capability? 

•What  role  are  the  depots  to  have  in  DoD  weapons  system  support?  Are  they  to  be 
only  used  for  legacy  systems  and  as  repairers  of  last  resort  when  a  contractor  is 
not  available,  or  are  they  to  be  a  key  source  of  repair  for  new  and  modified 
weapon  systems? 

•How  does  core  depot  maintenance  fit  into  a  DoD  support  scenario  in  light  of 
DoD’s  preference  for  using  performance-based  logistics? 

•If  the  maintenance  depots  are  to  remain  relevant  in  the  future,  what  actions  are 
needed  to  ensure  they  are  modernized  and  capable  of  performing  maintenance  on 
new  systems? 

•As  it  becomes  more  difficult  to  distinguish  depot  from  intermediate  maintenance 
and  maintenance  from  other  supportability  functions,  to  what  extent  does  it 
remain  practicable  to  quantify  a  balance  of  public  and  private  sector  depot 
maintenance? 

•Is  it  important  for  DoD  to  continue  to  define  some  level  of  core  capability  that  it 
should  perform  using  DoD  military  or  civilian  employees? 
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•What  kind  of  capability,  if  any,  should  DoD  retain  in  organic  depots  to  assure 
that  they  have  a  ready  and  controlled  source  of  technical  competence  and  the 
resources  necessary  to  ensure  its  ability  to  respond  to  current  and  future  national 
defense  emergencies? 

•To  what  extent  should  the  depots  be  capable  of  performing  maintenance  on 
weapon  system  commodities? 

•How  would  DoD  assure  that  maintenance  would  continue  to  be  cost  effective  if 
the  depots  were  no  longer  available  as  an  alternative  source  of  repair? 

•Should  there  continue  to  be  a  required  level  of  organic  logistics  capability  and  if 
so  should  it  be  only  for  maintenance? 

•What  changes  can  be  made  to  the  50/50  and  or  core  process  to  improve  their 
accuracy  and  internal  controls? 

•Could  a  modified  strategic-level  core  process  be  developed  to  simplify  the 
development  of  required  information  regarding  essential  capabilities  to  be 
retained  in  the  military  depots? 
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DoD’s  Report  to  Coneress  on  Its  Public-Private  Partnerships  at  Its  Centers  of 
Industrial  and  Technical  Excellence  fCITEs)  Is  Not  Complete  and  Additional 
Information  Would  be  Useful  (GAO-08-902R) 

This  GAO  report  was  authored  for  the  ehairman  and  ranking  member  of  both  the 
Senate  and  House  of  Representatives  Committee  on  Armed  Services.  The  content  of  the 
report  is  an  assessment  of  the  DoD  report  to  Congress  on  public-private  partnerships  at  its 
CITES  and  contained  the  following  six  reporting  elements:  (1)  common  approaches  and 
procedures  for  DoD  CITEs  to  use  in  the  implementation  of  partnerships;  (2)  consistent 
cost  methodologies  and  reimbursement  guidance  applicable  to  maintenance  and  repair 
workload  performed  by  federal  personnel  participating  in  public-private  partnerships;  (3) 
implementation  procedures  for  completing  contract  negotiation  for  partnerships  within  12 
months  of  initiating  negotiations;  (4)  the  secretary’s  use  of  commercial  practices  in 
partnerships  to  replace  existing  inventory  and  component  management,  technical 

publication  data,  document  management,  equipment  maintenance,  and  calibration 

1 

requirements;  (5)  delegation  during  a  partnership  of  Class  2  design  authority  based  on 
commercial  practices  to  maintain  the  form,  fit,  and  function  of  a  weapons  system 
platform,  major  end  item,  component  of  a  major  end  item,  or  article;  and  (6)  plans  to 
expand  core  capabilities  through  the  use  of  partnerships  at  DoD  CITEs. 

Of  note  in  this  report  is  the  GAO  description  of  private-public  partnering.  The 
GAO  describes  these  partnerships  as  cooperative  arrangements  between  a  depot-level 
maintenance  activity  and  one  or  more  private  sector  entities  to  perform  DoD  or  defense- 
related  work,  to  utilize  DoD  depot  facilities  and  equipment,  or  both. 
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Actions  Needed  to  Identify  and  Establish  Core  Capability  at  Military  Depots  (GAO- 
09-83) 

This  report  to  the  Subcommittee  on  Readiness  of  the  House  of  Representatives 
Committee  on  Armed  Services  provided  some  keen  insight  into  the  emerging  issues 
between  software  maintenance  and  core  capabilities. 

The  most  significant  issue  identified  in  this  paper  involved  the  Navy’s  handling  of 
software  maintenance.  The  Navy  contended  that  software  maintenance  is  not 
maintenance  in  the  pure  sense  of  the  word  as  it  does  not  return  an  item  to  its  original 
working  condition.  The  Navy  further  argued  that 


. .  .when  a  problem  caused  by  a  component  failure  is  found  in  hardware, 
the  solution  entails  bringing  the  hardware  item  back  to  its  original 
configuration  —  whereas  in  the  case  of  software,  when  a  problem  is  found 
and  corrected,  a  new  configuration  is  created.  Given  that,  command 
officials  felt  that  the  classic  organic  depot  scenario  of  an  artisan  using 
tools  to  restore  an  item  to  its  original  condition  would  never  apply  in  the 
software  world,  and  a  more  appropriate  term  than  software  maintenance 
would  be  software  support.  Further,  the  officials  felt  that  the  work 
reserved  for  organic  depots  under  the  core  statute  is  a  subset  of  a  much 
larger  world  defined  by  Section  2460,  and  “software  maintenance”  is 
depot  maintenance  in  this  broader  sense,  rather  than  in  terms  of  the  core 
statute. 

The  point  raised  by  the  Navy  is  key  and  can  easily  become  confusing.  The 
legislation  the  Navy  refers  to  simply  defines  what  constitutes  depot  maintenance  and  does 
not  mention  core  capability.  Section  2464  of  Title  10,  defines  what  constitutes  a  core 
capability  but  never  mentions  the  word  depot  directly,  although  it  is  common 
understanding  that  is  what  the  statute  is  referring  to.  The  point  of  the  Navy’s  argument  is 
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that  while  all  core  capabilities  are  depot  maintenance,  not  all  depot  maintenance 
constitutes  a  core  capability. 

The  GAO  disagreed  with  the  Navy’s  assessment  and  ultimately  the  DoD  did  as 
well.  The  Navy,  as  of  this  writing,  is  in  the  process  of  establishing  a  core  capability  for 
software  maintenance  within  their  depots. 
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Appendix  F:  QuOAT  Interview  Questions 


1.  Which  of  the  following  best  characterizes  your  next  OFP  release  compared 
to  your  last  OFP  release  (with  respect  to  requirements): 

a.  No  new  requirements 

b.  Few  new  requirements 

c.  Many  new  requirements 

d.  Extensive  new  requirements 


2.  Which  of  the  following  best  characterizes  your  next  OFP  release  compared 
to  your  last  OFP  release  (with  respect  to  the  baseline  affected  by  the 
changes): 

a.  Only  product  baseline  affected 

b.  Product  and/or  allocated  baseline  affected 

c.  Product  and  allocated  baseline  affected 

d.  Product  and/or  allocated  and  functional  baseline  affected 

3.  Which  of  the  following  best  characterizes  your  next  OFP  release  compared 
to  your  last  OFP  release  (with  respect  to  capabilities  related  to  the  aircraft 
mission  or  functionality  of  the  OFP): 

a.  No  new  capabilities/functionality  added 

b.  Few  new  capabilities/functionality  added 

c.  Many  new  capabilities/functionality  added 

d.  Extensive  new  capabilities/functionality  added 

4.  Which  of  the  following  best  characterizes  your  next  OFP  release  compared 
to  your  last  OFP  release  (with  respect  to  however  software  complexity  might 
be  measured  on  your  aircraft): 

a.  No  change  or  decreasing  complexity  of  the  OFP 

b.  Minimal  increase  in  complexity  of  the  OFP 

c.  Large  increase  in  the  complexity  of  the  OFP 

d.  Extensive  increase  in  the  complexity  of  the  OFP 

5.  Which  of  the  following  best  characterizes  your  next  OFP  release  (with 
respect  to  testing  required  prior  to  operational  use): 

a.  Bench  testing  only 

b.  Minimal  flight  testing 

c.  Moderate  flight  testing 

d.  Significant  flight  testing 
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6.  Was  new  operator  training,  qualification,  or  documentation  required  to  use 
the  new  OFP? 

a.  No 

b.  Yes 

7.  Which  of  the  following  best  characterizes  your  next  OFP  release  with 
respect  to  adding  hardware  to  the  aircraft  associated  with  the  OFP  (weapons, 
processors,  radar,  etc): 

a.  No 

b.  Yes 

8.  Which  of  the  following  best  characterizes  your  next  OFP  release  compared 
to  your  last  OFP  release  (with  respect  to  time  between  OFP  releases): 

a.  <  12  months  between  releases 

b.  12-18  months  between  releases 

c.  18-24  months  between  releases 

d.  >  24  months  between  releases 
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